Table arrangement for a directory service system and for related method facilitating queries for the directory

ABSTRACT

A directory services system, such as one providing a X.500 or LDAP directory service, having a design and a method of operation which facilitates queries in and out of the directory, table organisation/layout and clustering. In the arrangement of the directory service, tables are organized corresponding to their function, thereby permitting an arrangement based on service modeling and functional organisation that permits clustering. A preferred layout design incorporates principal, conceptual, logical and/or physical designs.

[0001] This is a divisional of U.S. Ser. No. 08/793,575, which iscurrently pending and which is incorporated herein by reference in itsentirety.

BACKGROUND OF THE INVENTION

[0002] 1. Field of the Invention

[0003] The present invention relates to the field of directory services.In particular, the present invention is directed to application ofX.500, LDAP and similar services to a relational database, a databasedesign and use of the database to perform X.500 services.

[0004] One aspect of the invention relates to the design of a directoryservice(s) system, including table organisation and clustering, andmethod of operation which facilitates queries in and out of thedirectory.

[0005] Other aspects of the present disclosure are directed to animplementation using a RDBMS (Relational Database Management System) andalso a table structure and methods of operation of a databaseapplication.

[0006] 2. Description of the Related Art

[0007] X.500 is the International Standard for Electronic Directories[CCITT89 or ITU93]. These standards define the services, protocols andinformation model of a very flexible and general purpose directory.X.500 is applicable to information systems where the data is fairlystatic (e.g. telephone directory) but may need to be distributed (e.g.across organisations or countries), extensible (e.g. store names,addresses, job titles, devices etc.), object oriented (i.e. to enforcerules on the data) and/or accessed remotely.

[0008] Relational Database Management System

[0009] (RDBMS) provide facilities for applications to store andmanipulate data. Amongst the many features that they offer are dataintegrity, consistency, concurrency, indexing mechanisms, queryoptimisation, recovery, roll-back, security. They also provide manytools for performance tuning, import/export, backup, auditing andapplication development.

[0010] RDBMS are the preferred choice of most large scale managers ofdata. They are readily available and known to be reliable and containmany useful management tools. There is a large base of RDBMSinstallations and therefore a large amount of existing expertise andinvestment in people and procedures to run these systems, and so datamanagers are looking to use this when acquiring new systems. Mostrelational database products support the industry standard SQL(Structured Query Language).

[0011] There has also been a move towards Object Oriented systems whichprovide data extensibility and the ability to handle arbitrarily complexdata items. In addition, many corporations and government departmentshave large numbers of database applications which are notinterconnected. Data managers are looking for solutions which enablethem to integrate their data, and to simplify the management of thatdata. X.500 and it's associated standards provide a framework and adegree of functionality that enables this to be achieved. The fact thatX.500 is an international standard means that data connectivity can beachieved across corporations and between different countries.

[0012] The problem, therefore, is to address the need of data managersand implement X.500 with all the flexibility of object-oriented systemsbut using an SQL product so that it can achieve the scalability andperformance inherent in relational systems coupled with the stability,robustness, portability and cost-effectiveness of current SQL products.

[0013] There have been a number of attempts of solving the above problemand over a considerable period of time. None of the attempts haveresulted in a product which has proven to be commercially accepted bythe market, and thus in the market place there is a long felt need yetto be addressed.

[0014]FIG. 1 shows an abstract from the “GOSIPNews” issue No. 4, datedApril 1994 (Source: “Interoperability Products” distributed in Australiaby the Centre for Open Systems) and which lists X.500 products currentlyavailable. None of these products use a SQL database as an underlyingdata store, and none of these products therefore address successfullythe market need of implementing X.500 using an SQL RDBMS.

[0015] The Proceedings of IFIP WG6.6 International Symposium (ISBN: 0444889 167) have published a paper presented by Francois Perruchond, CunoLanz, and Bernard Plattner and entitled “A Relational Data Base Designfor an X.500 Directory System Agent”. The Directory System disclosed, aswith many prior art systems, is relatively slow in operation,particularly where the database is relatively extensive and isincomplete in its implementation of X.500, such as aliases, subsearchand entry information.

[0016] Another attempt is disclosed in the proceedings of IREE, ISBN0909 394 253, proceedings Apr. 22-24, 1991 by C. M. R. Leung. In thatdisclosure, there is described a database scheme in which a single entrytable holds detailed information about each directory object, and isalso incomplete in its implementation of X.500.

[0017] This approach has been discredited by a number of text books andknowledge in the art, such as “Object-Oriented Modeling and Design” byJ. Rumbaugh, et al, 1991, ISBN 0-13-630054-5, in which at paragraph17.3.8 it is clearly stated that “putting all entities in the one tableis not a good approach to relational database design”.

[0018] As noted above, there have been a number of attempts made toaddress prior art problems, but none of the attempts have resulted in aproduct that has proven to be commercially accepted by the market. Inparticular, the prior art has been unable to address problems that areassociated with queries in and out of the directory, table organisationand layout, and clustering.

SUMMARY OF INVENTION

[0019] An object of the present inventions is to address problemsassociated with the prior art relating to design of a directoryservice(s) system and method of operation which facilitates queries inand out of the directory, table organisation/layout and clustering, orat least one of the prior art problems.

[0020] The present invention provides a directory service arrangement inwhich tables are organised corresponding to their function. Preferably,a directory service is provided in which arbitrary data is processedusing a fixed set of queries/services.

[0021] Furthermore, in the present invention each service is modeled,instead of each data type as seen in the prior art, and relationshipsare defined between each service, rather than between each data type asin the prior art. Implementation of service modeling using relationalqueries to satisfy directory services, such as X.500 services, enablesthe benefits of RDBMS to be optimally exploited.

[0022] Moreover, a directory service arrangement that is based onservice modeling and functional organisation leads to clustering and apreferred layout design. In clustering, data of the same type andsimilar values are clustered in the same area of a storage medium, suchas a disk. The number of disk pages that have to be accessed are thensignificantly reduced. The preferred, but not only, layout design thatincorporates principal, conceptual, logical and/or physical designs, issubsequently described and illustrated in the accompanying tables andfigures.

[0023] A further aspect of invention resides in providing a directoryservices database in which tables are arranged according to a conceptualdesign. The conceptual design includes at least attribute, object andhierarchy tables. The attribute table allows new attribute types to bedefined by adding respective rows to this table. The object tabledefines the attributes within each object. The hierarchy table definesthe relationship between objects.

[0024] A further aspect of invention is a method of arranging tables ofa directory service, such as a X.500 or LDAP directory service, themethod including:

[0025] decomposing tables around primary service relationships and

[0026] deriving secondary services via joins.

[0027] Preferably, in applying service decomposition, at least one ofthe following consideration are made:

[0028] (a) Columns that have strong relationships are preferred to bekept together (to avoid unnecessary joins);

[0029] (b) If the number of significant rows in a given column isindependent of the other related columns, then that given column is acandidate for a separate table.

[0030] (c) If a column is only used for locating information (input) oronly used for returning results (output) then it is a candidate for itsown table.

[0031] (d) If a column is used as a key for more than one service thenit is preferred to be a primary key and therefore in its own table,since each table can have only one primary key.

[0032] (e) Keys are preferred to be unique or at least strong(non-repetitious).

[0033] Preferably, the hierarchy table can be decomposed into at least 4tables, comprising a DIT (Directory Information Tree includinginformation required for navigation), NAME (including informationrequired for returning names (raw RDN)), TREE (including informationabout an entry's path) and ALIAS (includes entries that are aliases), ortheir equivalent.

[0034] Preferably, the object table can be decomposed into at least 2tables, namely SEARCH (used to resolve filters in a Search service andincludes one row for each attribute value of each entry) and ENTRY (usedto return values in Read and Search services and includes one row foreach attribute value,of each entry), or their equivalent.

[0035] Preferably, the invention includes a number of tables and designshaving characteristics and relationships, as illustrated in FIGS. 2A and2B.

[0036] A detailed description of the present invention can be found atleast in the summary of invention, and in sections 1, 2, 4,(particularly 4.1 and 4.6) and 6 of the description of the preferredembodiments, and the related Figures.

[0037] With regard to the remainder of the specification as a whole, ingeneral, it seeks to disclose a number of other inventions related tothe implementation of X.500 services in a RDBMS which supports SQL orany other relational language. X.500 services can be invoked via anumber of protocols, such as X.500 and LDAP.

[0038] The scope of the present invention is outlined in thisspecification, including the claims.

[0039] In this document, at the time of filing, SQL is the most popularrelational language and although it is only one form of relationallanguage, the intent of the present invention is to have application toany other form of relational language, not just SQL.

[0040] These inventions can be related to the following headings:

[0041] 1. Principal Design

[0042] 2. Conceptual Design

[0043] 3. Conceptual Method(s)

[0044] 4. Logical Design

[0045] 5. Logical Method(s)

[0046] 6. Physical Design

[0047] 7. Example Implementation

[0048] The X.500 standard in no way dictates how the directory is to beimplemented, only its capabilities and behaviour. One key to solving theimplementation problem is the realisation that X.500 defines a fixed setof services (e.g. Add, Modify, Search etc.) that can operate onarbitrary data.

[0049] It has been discovered that problems associated with the priorart may be alleviated by a unique approach, by what may be described asinverting relational theory modeling from a data modeling approach to aservice modeling approach. That is, from the problem of:

[0050] processing arbitrary queries on a fixed set of data to thepresent approach of processing arbitrary data using a fixed set ofqueries/services.

[0051] Each service is modelled (instead of each data type) and therelationships between each service defined (instead of the relationshipsbetween each data type).

[0052] Implementation of service modeling using relational queries tosatisfy X.500 services enables benefits of RDBMS to be exploited.

[0053] The benefits of this approach are many. A summary is illustratedin FIG. 3. Some of the benefits include:

[0054] relatively fast starting time.

[0055] the ability to reduce memory requirements relative to memoryresident systems.

[0056] the ability to base X.500 on any SQL database and thereby protectthe investment in products, expertise and procedures in managingexisting systems.

[0057] the ability to achieve performance relatively independent of sizeand relatively independent of the complexity of the data type. Everydata type is treated generically. Every data type has an index on it.The result of indexing gives the ability to efficiently search thedirectory without caching large portions of directory into memory.Unlike the prior art where either only one index can be used to satisfyone given query or large portions of information is system intensivelycached and searched in memory.

[0058] the ability to support different languages (e.g. Spanish, Hebrewand Kanji) which may have various collating sequences. Single, double orother byte character sets may also be supported.

[0059] using a disk based model to minimise I/O and efficiently retrieveI/O.

[0060] the ability to service complex X.500 searches.

[0061] the ability to create X.500 databases of far greater size thanpreviously possible, without compromising performance or robustness. Thedatabases can be small or large (250,000, 1 million or more entries).

[0062] an optimal table design minimises wastage of disk space.

[0063] the ability to leverage off hundreds of man years of relationaldatabase developments and use “industrial strength” databases withproven reliability, integrity, security and tools for developing highperformance applications.

[0064] Based on this unique approach, the following disclosure willdetail a number of inventions in an order with reference to FIGS. 2A and2B, which illustrates schematically an overview of the present X.500system. The table and column, names, order of columns and numeric valuesdisclosed are given on an arbitrary basis in the overview. The number ofcolumns disclosed represent a preferred operable requirement. Additionalcolumns do not alter the use of the table as herein contemplated.

BRIEF DESCRIPTION OF THE DRAWINGS

[0065]FIG. 1 is an illustration of a table that lists X.500 productscurrently available, none of which use a SQL data base as an underlyingdata store.

[0066]FIG. 2A is an illustration schematically of an overview of thepresent invention, particularly the principal design and thecorresponding conceptual design, as applied to the provision of a tablestructure for an X.500 system.

[0067]FIG. 2B is an illustration schematically of an overview of thepresent invention, particularly the logical design and the correspondingphysical design, as applied to the provision of a table structure for anX.500 system.

[0068]FIG. 3 is an illustration of a pie chart that provides a summaryrepresentation of the benefits of implementing service modeling usingrelational queries to satisfy X.500 services.

[0069]FIG. 4 is an illustration of a hierarchy within a hypotheticalorganization, arranged as a tree, that is used to explain the servicesthat may be provided according to the present invention.

[0070]FIG. 5 is an illustration of a hierarchy within a hypotheticalorganization, arranged as a tree, that has an alias referencing adifferent branch of the tree, according to the present invention.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0071] 1. Principal Design

[0072] The X.500 prior art attempts at implementation have been unableto overcome the relatively basic structural and operational differencesbetween the X.500 requirements and functionality and SQL. The X.500standard has a particular structure by nature, whereas SQL is designedto operate on relational structured tables.

[0073] For a typical relational database application, the nature of datais well known, i.e. tables will consist of a number of columns and eachcolumn contains data relating to a particular data type (see Table B1).The different data types that can be stored is limited to the columns ofthe table. The data types are also limited to the types supported by thedatabase (e.g. string, numeric, money, date). The database may alsostore data of a form not understood by the database per se, butunderstood by the application e.g. binary data. TABLE B1 Employee TableName Surname Title Phone Chris MASTERS Sales Manager 03 727-9456 AlanaMORGAN Sales Support 03 727-9455 . . . . . . . . . . . .

[0074] If a new data type needs to be added (e.g. mobile) then a newcolumn will have to be added to the table. This can cause problems ifdata table changes are not easy to implement. Also if the new data typeis not well used (e.g. less than 1% of the organisation) thensignificant redundant data storage may result. See Table B2. TABLE B2Employee Table Name Surname Title Phone Mobile Chris MASTERS SalesManager 03 727-9456 018 042671 Alana MORGAN Sales Support 03 727-9455 .. . . . . . . . . . . . . .

[0075] In essence, one invention in the application of X.500 resides inovercoming the extensibility by representing the X.500 attributes of theprior art: empl # name age salary

[0076] as described above, as type syntax value,

[0077] the latter representation being an extensible representation andis thus adapted to implementation with SQL. The latter representation isknown as meta-data. The meta-data “value” may be binary.

[0078] A further development based on the above principal design is theadaption of the ‘principal design’ to X.500. This adaption has beenrealised by the provision of a ‘property table’, in which object nameand parent name is added to the ‘principal design’.

[0079] Further benefits accrue from the implementation disclosed above;including:

[0080] a. independence of complexity of filter—the implementationdisclosed may utilise a query optimiser provided in SQL, and thereforethere is no need to replicate a query optimiser in each proprietarydatabase to which the present invention is applied,

[0081] b. independence of size—the implementation disclosed has theability to be scaled,

[0082] c. independence of depth of tree—the implementation disclosed hashierarchy comparability,

[0083] d. performance—if index is put on the type column, then each andevery type is indexed.

[0084] 2. Conceptual Design

[0085] The prior art has had difficulty in implementing X.500 as it hasnot been structured for extensibility, object oriented and hierarchywhich are requirements of X.500.

[0086] This is addressed, in one form, by functionally decomposing the‘property table’ and thus resulting in what is called the ConceptualDesign.

[0087] The conceptual design resides in providing at least one of:

[0088] 1. Attribute table, where extensibility is addressed by allowingthe definition of a new attribute type in this table by adding a row tothe table;

[0089] 2. Object table, which defines the attributes within each object;and/or

[0090] 3. Hierarchy table, which defines the relationship between theobjects.

[0091] In another invention, this problem is addressed by providingtable structures in accordance with those disclosed in FIGS. 2A and 2B.

[0092] Yet further inventions reside in addressing problems of datatolerance by providing in the present X.500 system for the replacementof the ‘value’ column of the object table with value ‘norm’ and value‘raw’ columns and/or replacing the RDN column in the hierarchy tablewith ‘name norm’ and ‘name raw’ columns.

[0093] Further, the difficulty in prior art of accommodating aliases isaddressed in the present X.500 system by providing an ‘alias’ column inthe hierarchy table. The ‘alias’ column is flagged to indicate that,that entry is an alias.

[0094] Further refinement may be provided by replacing the ‘alias’column with alias and A-EID columns. The A-EID provides informationabout where the alias points.

[0095] Still further refinement may be provided by replacing the‘parent’ column in the hierarchy table with ‘parent’ and ‘path’ columns.

[0096] The ‘path’ addresses the problem of implementing X.500 search,with aliases and subtrees. The ‘path’ has at least two uniqueproperties: a) to determine the absolute position in the hierarchy; andb) it is used to determine if an entry is in a given subtree by itsprefix.

[0097] 3. Conceptual Method

[0098] A number of unique methods of interrogating the conceptual designare disclosed in the detailed description following, including:

[0099] a) mapping the X.500 services into a sequence of SQL statements;

[0100] b) the search strategy is to apply the filter over the searcharea using the path or parent columns, and/or;

[0101] c) in dealing with aliases during navigation—where an aliaspoints is cached In the A EID column;

[0102] d) in dealing with alias during search—find the unique set ofbase objects which define areas of the tree that need to be searched,and then apply b) above to each area of the tree.

[0103] A further invention is realised by using the attribute table forincoming data to find the AID from the X.500 object ID and outgoing dataread from the database, vice versa.

[0104] Furthermore, for any incoming distinguished name, it is navigatedto its appropriate EID, then each search is performed as required byX.500.

[0105] Still furthermore, for a search, filter and subtree searches canbe provided by a single pass resolution and using the path column. Oneinvention is to utilise a ‘path’ field to simultaneously apply anarbitrary filter over an arbitrary subtree. The complications of aliasesis handled by applying the above method to a uniquely resolved subtree.

[0106] Yet another unique method is to store the “path” of each entry asa string. Each path will then be prefixed by the path of its parententry. This is useful for the filter in the search service.

[0107] 4. Logical Design

[0108] The logical design is based on a service decomposition of theconceptual design, though the realisation that X.500 service componentsare independent.

[0109] The advantages accruing from this include:

[0110] 1. Reduces the number of indexes per table, as more tables areprovided. It has been found that primary indexes are most efficient(speed, size) and secondary indexes may have large overheads (speed,size).

[0111] 2. Enable data in tables to be clustered. Clustering occurs as aresult of its primary key (storage structure) and thus data may beorganised on disk around its key. E.g. for the ‘search’ table, surnamesmay be clustered together.

[0112] 3. Management—smaller tables are easier to manage, e.g. faster toupdate indexes, collect statistics, audit, backup, etc.

[0113] 4. Reduced I/O—speed improvements due to smaller rows, means morerows per page and thus operations perform less I/O's.

[0114] 5. Logical Methods

[0115] A number of unique methods of interrogating the logical designtables are disclosed in the detailed description following.

[0116] In addition, one method resides in caching the attribute table.Thus, (with the exception of initial loading) no SQL statements areissued to the database. In the present X.500 system, conversions areperformed in memory. This provides a substantial speed advantage.

[0117] Further, validation is performed in memory which avoids databaseroll-back. Roll-backs are time and system consuming.

[0118] Still further, for the arbitrary filter, a dynamic SQL equivalentis built. This enables arbitrary complexity in X.500 searches.

[0119] Also for search results, the present system utilises setorientation queries of SQL to avoid ‘row at a time’ processing. Thussearch results may be assembled in parallel in memory.

[0120] 6. Physical Design

[0121] New tables and new columns are introduced to overcome columnwidth and key size restrictions and to achieve space optimisations.

[0122] The following text is a disclosure of embodiments of theinventions outlined:

[0123] 1. Principal Design

[0124] With reference to FIG. 2A, the principal design addresses thebasic problem of representing the extensible, object oriented andhierarchical nature of X.500 in relational tables. In this section itwill be disclosed (with examples) that the principal table design can berepresented by a single table as shown in Table 1 below. TABLE 1 X.500Property Table object name parent name type syntax value

[0125] Throughout this and the following sections all column names andtheir positions in each table are arbitrary. The intent is to definewhat they contain and how they are used.

[0126] 1.1 Extensibility

[0127] For a typical relational database application, the nature of datais well known, i.e., tables will consist of a number of columns and eachcolumn contains data relating to a particular data type (see Table1.1a). The table is self descriptive, i.e. the relations between dataitems is implied by being on the same row (this is the basis ofrelational theory). TABLE 1.1a Typical relational table name surnametitle phone Chris MASTERS Sales Manager 03 727-9456 Alana MORGAN SalesSupport 03 727-9455 . . . . . . . . . . . .

[0128] However, the above approach is not extensible because the numberof different data types is limited to the number of columns of thetable. If a new data type needs to be added (e.g. mobile phone number)then a new column will have to be added to the table (see Table 1.1b).Any application accessing this table will need to be updated toexplicitly query it. TABLE 1.1b Relational table with an extra columnname surname title phone mobile Chris MASTERS Sales Manager 03 727-9456018 042671 Alana MORGAN Sales Support 03 727-9455 . . . . . . . . . . .. . . .

[0129] Other problems also exist in practice. If the new data type isnot well used (e.g. less than 1% of the organisation has a mobile phone)then the table will be sparse (e.g. if a given person does not have amobile then that row/column entry will be NULL). Also, the data typesare limited to the types supported by the database (e.g. string,numeric, money, date, etc.).

[0130] The solution is to treat the data types as generic. The presentinvention adopts the method of representing arbitrary attributes (e.g.XOM [X/OPEN Object Management] API [Application Programming Interface])as a type, syntax, value combination (see Table 1.1c) TABLE 1.1cRepresenting arbitrary attributes type syntax value Name String ChrisSurname String MASTERS Title String Sales Manager Phone Numeric 03727-9456 Mobile Numeric 018 042671

[0131] 1.2 Object Oriented

[0132] X.500 defines objects (e.g. people, organisations, etc.) whichmay contain an arbitrary number of “attributes”. Since many objects mustappear in the table a mechanism is required to distinguish each object.An “object name” column is added to the table for this purpose (seeTable 1.2a). TABLE 1.2a Representing objects with arbitrary valuesobject name type syntax value Chris Masters Name String Chris ChrisMasters Surname String MASTERS Chris Masters Title String Sales ManagerChris Masters Phone Numeric 03 727-9456 Chris Masters Mobile Numeric 018042671 Alana Morgan Name String Alana Alana Morgan Surname String MORGANAlana Morgan Title String Sales Support Alana Morgan Phone Numeric 03727-9455

[0133] The above method allows any number of attributes to be assigned(related) to an entry. These attributes could be of arbitrary complexity(e.g. a multi-line postal address could be handled). As the number ofcolumns is fixed new attributes can be added to any object withouthaving to redefine the application. If a new attribute is added then anapplication that reads the entry will get back an extra row.

[0134] 1.3 Hierarchical

[0135] A method of representing hierarchical systems (e.g. partsexplosion) is to use a parent/child combination (see Table 1.3a) TABLE1.3a Parts explosion hierarchy parent child car engine car fuel system .. . . . . engine carburettor engine pistons . . . . . . carburettor fuelvalve carburettor air valve . . . . . .

[0136] X.500 defines its objects to be hierarchical. The relationshipsbetween objects follow a tree structure where each object has a parentobject and each parent can have zero or more children. This relationshipcan be represented in a general PROPERTY table by the addition of a“parent name” column, which is used to store the name of the parentobject (see Table 1.3b). FIG. 1.3b - X.500 Property Table object nameparent name type syntax value Datacraft root Organisation StringDatacraft Datacraft root Address Postal PO Box 353 Address Croydon VICChris Masters Datacraft Name String Chris Chris Masters DatacraftSurname String MASTERS Chris Masters Datacraft Title String SalesManager Chris Masters Datacraft Phone Numeric 03 727-9456 Chris MastersDatacraft Mobile Numeric 018 042671 Alana Morgan Datacraft Name StringAlana Alana Morgan Datacraft Surname String MORGAN Alana MorganDatacraft Title String Sales Support Alana Morgan Datacraft PhoneNumeric 03 727-9455

[0137] Note that the root of the tree has no parent. Thus, if both Chrisand Alana work for Datacraft and Datacraft is a child of the root thenwe can say that Chris and Alana are children of Datacraft and thatDatacraft is the parent of Chris and Alana.

[0138] 2. Conceptual Design

[0139] In Section 1 it was shown that a single Property Table couldrepresent the extensible, object oriented and hierarchical nature ofX.500 (see Table 2a). TABLE 2a Property Table object name parent nametype syntax value

[0140] With reference to FIG. 2A in this section it will be shown thatfull X.500 functionality can be represented by using three tables asshown below (see Table 2b and FIG. 2A). TABLE 2b Full Conceptual DesignHierarchy Table EID Parent Path Alias A_EID NameNorm NameRaw ObjectTable EID AID VID Disting ValueNorm ValueRaw Attribute Table AID TypeSyntax ObjectId

[0141] The conceptual design addresses major problems with implementingfull X.500 functionality in relational tables. As each major designissue is presented, examples are provided to illustrate the solution.

[0142] 2.1 Functional Decomposition

[0143] The Property Table (FIG. 2A) can be decomposed into separatetables that reflect the hierarchical, object oriented and extensiblenature of X.500, preferably as follows;

[0144] a Hierarchy Table which defines the structural relationshipbetween objects.

[0145] an Object Table which defines the attribute values within eachobject.

[0146] an Attribute Table which defines the different attribute types.

[0147] These tables result from a process called functionaldecomposition.

[0148] To address the problem of correlating the relationships betweentables, arbitrary numeric identifiers are introduced. The EID or “entryidentifier” correlates each object with its hierarchy information. TheAID or “attribute identifier” correlates each value in the object tablewith its attribute information.

[0149] The design is considered very efficient because the repeatinggroups in the Property table (type-syntax and object name-parent name)have been removed. Also, for SQL, the joining columns are simpleintegers. TABLE 2.1 Basic Conceptual Design Hierarchy Table EID ParentName 10 0 Datacraft 30 10 Chris Masters 31 10 Alana Morgan Object TableEID AID Value 10 10 Datacraft 10 16 PO Box 123 CROYDON 30 3 Chris 30 4MASTERS 30 12 Sales Manager 30 20 03 727-9456 31 3 Alana 31 4 MORGAN 3112 Sales Support 31 20 03 727-9455 Attribute Table AID Type Syntax 3Name string 4 Surname string 10 Organisation string 12 Title string 16Postal Address address string 20 Phone telephone string

[0150] 2.2 X.500 Attributes

[0151] X.500 attributes have a protocol identifier which is transferredwhen any data is communicated between end systems. These identifiers areinternationally defined and are called OBJECT IDENTIFIERS (e.g. 2.5.4.4means a surname string). Thus an “ObjectId” column can be added to theAttribute table so that conversions between X.500 object identifiers andthe internal attribute identifiers can be performed.

[0152] In addition, X.500 allows an attribute to have an arbitrarynumber of values (e.g. the mobile phone could be treated just as asecond telephone number). Thus a “value identifier” or VID is introducedto identify values within an attribute in the Object Table. TABLE 2.2Conceptual Design with X.500 attributes Hierarchy Table EID Parent Name10 0 Datacraft 30 10 Chris Masters 31 10 Alana Morgan Object Table EIDAID VID Value 10 10 1 Datacraft 10 16 1 PO Box 123 CROYDON 30 3 1 Chris30 4 1 MASTERS 30 12 1 Sales Manager 30 20 1 03 727-9456 30 20 2 018042671 31 3 1 Alana 31 4 1 MORGAN 31 12 1 Sales Support 31 20 1 03727-9455 Attribute Table AID Type Syntax ObjectId 3 Name string 2.5.4.34 Surname string 2.5.4.4 10 Organisation string 2.5.4.10 12 Title string2.5.4.12 16 Postal Address address string 2.5.4.16 20 Phone telephonestring 2.5.4.20

[0153] 2.3 X.500 Names

[0154] In X.500, each entry uses one or more of its attribute values(Distinguished Values) for naming the entry. A “Disting” column is addedto the Object Table to flag the distinguished values.

[0155] The Distinguished Values combine to form a Relative DistinguishedName (RDN) which names the entry. The “Name” column in the Hierarchytable stores the RDN. This is an optimisation that negates the need forthe RDN to be constructed from the distinguished values in the Objecttable.

[0156] An entry is uniquely named by a Distinguished Name (DN) whichconsists of all the RDN's of the of its ancestors down from the root andthe RDN of the object itself. An innovation is to add a “path” column tothe Hierarchy table which defines the absolute position of the entry inthe tree as a list of EID's. The path has three important properties;

[0157] 1) enables fast construction of DN's, (the EID list defines allthe RDN's)

[0158] 2) enables fast subtree searches (see Conceptual Methods),

[0159] 3) it is independent of its DN (any of the RDN's in the DN can berenamed without affecting the path). TABLE 2.3 Conceptual Design withX.500 attributes and names Hierarchy Table EID Parent Path Name 10 0 10.Datacraft 30 10 10.30. Chris, MASTERS 31 10 10.31. Alana, MORGAN ObjectTable EID AID VID Disting Value 10 10 1 1 Datacraft 10 16 1 0 PO Box 123CROYDON 30 3 1 1 Chris 30 4 1 1 MASTERS 30 12 1 0 Sales Manager 30 20 10 03 727-9456 30 20 2 0 018 042671 31 3 1 1 Alana 31 4 1 1 MORGAN 31 121 0 Sales Support 31 20 1 0 03 727-9455 Attribute Table AID Type SyntaxObjectId 3 Name string 2.5.4.3 4 Surname string 2.5.4.4 10 Organisationstring 2.5.4.10 12 Title string 2.5.4.12 16 Postal Address addressstring 2.5.4.16 20 Phone telephone string 2.5.4.20

[0160] 2.4 X.500 Aliases

[0161] X.500 also has the concept of ‘aliases’. An alias objecteffectively points to another entry and thus provides an alternate namefor that entry. Thus an “alias” flag is added to the Hierarchy Table.When an alias is discovered during Navigation (i.e. the supplied DNcontains an alias), then the alias value must be read from the ObjectTable. This alias DN must be resolved to where the alias points beforeNavigation of the original entry can continue.

[0162] An innovation is to use an “aliased EID” column or A_EID to store“where” the alias “points to”. This removes the need to repeatedlynavigate through an alias. TABLE 2.4 Conceptual Design with X.500attributes, names and aliases Hierarchy Table EID Parent Path AliasA_EID Name 10 0 10. 0 0 Datacraft 30 10 10.30. 0 0 Chris, MASTERS 31 1010.31. 0 0 Alana, MORGAN 35 10 10.35. 1 31 Support Engineer Object TableEID AID VID Disting Value 10 10 1 1 Datacraft 10 16 1 0 PO Box 123CROYDON 30 3 1 1 Chris 30 4 1 1 MASTERS 30 12 1 0 Sales Manager 30 20 10 03 727-9456 30 20 2 0 018 042671 31 3 1 1 Alana 31 4 1 1 MORGAN 31 121 0 Sales Support 31 20 1 0 03 727-9455 35 4 1 1 Support Engineer 35 7 10 Datacraft/Alana, Morgan Attribute Table AID Type Syntax ObjectId  1Alias Name Distinguished 2.5.4.1 Name  3 Name string 2.5.4.3  4 Surnamestring 2.5.4.4 10 Organisation string 2.5.4.10 12 Title string 2.5.4.1216 Postal Address address string 2.5.4.16 20 Phone telephone string2.5.4.20

[0163] 2.5 X.500 Data Tolerance

[0164] Every X.500 attribute has a (internationally defined) syntax.X.500 attribute syntaxes define how each attribute should be treated. Inall string syntaxes (e.g. Printable, Numeric etc.) superfluous spacesshould be ignored. In some syntaxes the case is not important (e.g. CaseIgnore String and Case Ignore List) and so the names “Chris Masters”,“Chris MASTERS” and “ChRis MaSTeRS” are considered identical.

[0165] In order to do comparisons (e.g. search for a particular value),the syntax rules can be applied to create a normalised form (e.g. “CHRISMASTERS”). If this normalised form is stored in the database, then anyvariations in input form are effectively removed, and exact matching canbe used (which is necessary when using SQL).

[0166] Both the normalised data and “raw” data are stored in thedatabase. The “raw” data is necessary so that users can retrieve thedata in exactly the same format as it was originally input. As per theX.500 and LDAP standard, data received from a user, raw data, accordswith ASN.1 (Abstract Syntax Notation No. 1). Thus the “Name” column inthe Hierarchy Table becomes the “NameRaw” and a “NameNorm” column isadded. Similarly, the “Value” column in the Object Table becomes the“ValueRaw” and a “ValueNorm” column is added. TABLE 2.5 Full ConceptualDesign Hierarchy Table EID Parent Path Alias A_EID NameNorm NameRaw 10 010. 0 0 DATACRAFT Datacraft 30 10 10.30. 0 0 CHRIS, Chris, MASTERSMASTERS 31 10 10.31. 0 0 ALANA, Alana, MORGAN MORGAN 35 10 10.35. 1 31SUPPORT Support ENGINEER Engineer Object Table EID AID VID DistingValueNorm ValueRaw 10 10 1 1 DATACRAFT Datacraft 10 16 1 0 PO BOX 123 POBox 123 CROYDON CROYDON 30 3 1 1 CHRIS Chris 30 4 1 1 MASTERS MASTERS 3012 1 0 SALES MANAGER Sales Manager 30 20 1 0 037279456 03 727-9456 30 202 0 018321435 018 042671 31 3 1 1 ALANA Alana 31 4 1 1 MORGAN MORGAN 3112 1 0 SALES SUPPORT Sales Support 31 20 1 0 037279455 03 727-9455 35 41 1 SUPPORT Support Engineer ENGINEER 35 7 1 0 DATACRAFT/Datacraft/Alana, ALANA Morgan MORGAN Attribute Table AID Type SyntaxObjectId  1 Alias Name Distinguished 2.5.4.1 Name  3 Name Case IgnoreString 2.5.4.3  4 Surname Case Ignore String 2.5.4.4 10 OrganisationCase Ignore String 2.5.4.10 12 Title Case Ignore String 2.5.4.12 16Postal Address Case Ignore List 2.5.4.16 20 Phone Telephone String2.5.4.20

[0167] 3. Conceptual Methods

[0168] This section introduces the basic X.500 services and shows howthe conceptual table design, shown in Table 3a or FIG. 2A, is sufficientto implement X.500 services and their complexities. TABLE 3a ConceptualTable Design Hierarchy Table EID Parent Path Alias A_EID NameNormNameRaw Object Table EID AID VID Disting ValueNorm ValueRaw AttributeTable AID Type Syntax ObjectId

[0169] The example hierarchy shown in Table 3b, as seen in FIG. 4, willbe used to illustrate these services. Each name in the diagramrepresents an object entry in the database. The triangle represents analias entry, and the dotted line represents the connection between thealias entry and the object that it points to. The numbers next to eachentry are the entry EID's.

[0170] In the example, entry “1” has an RDN with a value of “Datacraft”,entry “11” has an RDN with a value of “Sales”, entry “20” has an RDNwith a value of “Network Products” and entry “31” has an RDN with avalue of “Alana Morgan”. The DN of entry “31” is made up of a sequenceof RDN's, namely, ““Datacraft” , “Sales”, “Network Products”, “AlanaMorgan”.

[0171] The alias entry “Datacraft/Networks” points to the entry“Datacraft”, “Sales”, “Network Products”. When navigating to this entrythe navigate process would find the alias entry, then find the DN of theobject pointed to by the alias and then navigate from the root to theobject entry returning an EID of “20” and a path of “1.11.20.”.

[0172] Listed below are sample tables which show how data is stored. TheHierarchy table (Table 3c) shows how the entries for the examplehierarchy are stored. The Attribute table (Table 3e) shows attributeswhich are contained in the entry “Datacraft/Sales/Network Products/ChrisMasters”. The Object table (Table 3d) shows how the values of theseattributes are stored. TABLE 3c Sample Hierarchy Table EID Parent PathAlias A_EID NameNorm NameRaw  1 0 1. 0 0 DATACRAFT [Datacraft] 10 11.10. 1 20 NETWORKS [Networks] 11 1 1.11. 0 0 SALES [Sales] 12 1 1.12. 00 MARKETING [Marketing] 20 11 1.11.20. 0 0 NETWORK [Network PRODUCTSProducts] 30 20 1.11.20.30. 0 0 CHRIS MASTERS [Chris Masters] 31 201.11.20.31. 0 0 ALANA MORGAN [Alana Morgan] 32 20 1.11.20.32. 0 0 PETEREVANS [Peter Evans]

[0173] TABLE 3d Sample Object Table EID AID VID Disting ValueNormValueRaw 30 3 0 1 CHRIS [Chris] 30 4 0 1 MASTERS [Masters] 30 12 0 0SALES MANAGER [Sales Manager] 30 20 0 0 03 727 9456 [(03) 727-9456] 3020 1 0 018 042 671 [(018) - 042 671]

[0174] TABLE 3e Sample Attribute Table AID Type Syntax ObjectID 3commonName caseIgnoreString 2.5.4.3 4 surname caseIgnoreString 2.5.4.412 title caseIgnoreString 2.5.4.12 20 telephoneNumber telephoneNumber2.5.4.20

[0175] Distinguished Names

[0176] For the entry shown in the sample Object Table (Table 3d) two ofthe attributes, commonName and surname, are distinguished values (ornaming values) which combine to form the RDN for the entry. This RDN isstored in the Hierarchy Table.

[0177] Multi-Valued Attributes

[0178] In X.500, it is permissible for an attribute to be multi-valued.The VID column is used to distinguish between values for an attribute.In the sample Object Table, the telephoneNumber attribute ismulti-valued.

[0179] 3.1 Mapping Services to SQL

[0180] 3.1.1 Attribute Types and Values

[0181] Any data supplied by an X.500 service is supplied as a list ofObjectId's and their associated values. These must be converted intoAID's (using the Attribute table) and normalised values (using theObject table) for use by the X.500 application. The database returnsdata as AID's and Raw Values, which must then be converted intoObjectId's and their associated values in the X.500 result.

[0182] 3.1.2 Navigation

[0183] Each X.500 service supplies a Distinguished Name which isconverted into an EID for use by the X.500 application. When theapplication processes a service it returns one or more EID's. TheseEID's can then be translated back into Distinguished Names in the X.500result.

[0184] All X.500 services rely on navigating the directory tree. Tonavigate to a particular entry, the following procedure is performed:

[0185] Given the DN for the entry, locate the entry in the hierarchytable which has an RDN equal to the first RDN in the DN.

[0186] Store the EID.

[0187] Recursively, locate the entry which has an RDN equal to the nextRDN in the DN and a parent equal to the stored EID.

EXAMPLE

[0188] Navigate to the entry “Datacraft/Sales/Network Products/PeterEvans”. This will result in a number of select statements, with eachreturned EID being used as the value of the PARENT in the nextstatement.

[0189] select EID from HIERARCHY

[0190] where PARENT=0 and RDN=“DATACRAFT”

[0191] select EID from HIERARCHY

[0192] where PARENT=1 and RDN=“SALES”

[0193] select EID from HIERARCHY

[0194] where PARENT=11 and RDN=“NETWORK PRODUCTS”

[0195] select EID from HIERARCHY

[0196] where PARENT=20 and RDN=“PETER EVANS”

[0197] 3.1.3 Read

[0198] Selected attributes to be read can be supplied. Only the valuesof these attributes (if they are present in the entry) will be returned.

[0199] ‘Types only’ can be selected as a read option, in which case novalues will be returned. All types present in the entry, or thoseselected, will be returned.

[0200] Navigate to the entry to be read. Store the EID. In the ObjectTable, read the values of all rows which match the stored EID.

Example

[0201] Read the entry “Datacraft/HQ/Network Products” and return alltypes and values.

[0202] Navigate to the entry (as in 3.1.2) and then;

[0203] select AID, VALUERAW from OBJECT

[0204] where EID=20

[0205] 3.1.4 Compare

[0206] Compare returns a ‘matched’ or ‘not matched’ result. A raw valueis input but the compare is performed using the normalised value.

[0207] Navigate to the required entry. Store the EID. In the ObjectTable, test for a matching value in all rows which match the stored EIDand the specified AID.

Example

[0208] Compare the telephone Number “03 727 9256” with the entry“Datacraft/Sales/Network Products/Chris Masters”.

[0209] Navigate to the entry and then;

[0210] select VALUERAW from OBJECT

[0211] where EID=30

[0212] and AID=20

[0213] and VALUENORM=“03 727 9456”

[0214] If a value is selected then return “matched” else return “notmatched”.

[0215] 3.1.5 List

[0216] Navigate to the required entry. Store the EID. In the HierarchyTable, return the RDN's for all rows with a parent matching the storedEID.

Example

[0217] List from the entry “Datacraft/Sales”.

[0218] Navigate to the entry and then;

[0219] select NAMERAW from HIERARCHY

[0220] where PARENT=11

[0221] 3.1.6 Add Entry

[0222] Navigate to the required parent entry. Store the EID of theparent. Add a new EID to the Hierarchy table and add rows to the Objecttable for each value in the new entry.

Example

[0223] Add a new entry under the entry “Datacraft/Sales/NetworkProducts”.

[0224] Navigate to the entry and then;

[0225] insert into OBJECT

[0226] (EID, AID, VID, DISTING, VALUENORM, VALUERAW)

[0227] values (33, 3, 1, 1, EDWIN MAHER, Edwin Maher) and

[0228] insert into HIERARCHY

[0229] (EID, PARENT, PATH, ALIAS, A-EID, NAMENORM, NAMERAW)

[0230] values (33, 20, 1.11.20.33.,0,0, EDWIN MAHER, Edwin Maher)

[0231] 3.1.7 Remove Entry

[0232] Navigate to the required entry. Check that the entry is a leaf onthe tree, (i.e. check that it has no subordinate entries on the tree).Store the EID. Remove the entry from the Hierarchy table. In the ObjectTable, remove all rows which match the stored EID.

Example

[0233] Remove an entry (with EID=33) under the entry“Datacraft/Sales/Network Products”.

[0234] Navigate to the entry and then;

[0235] delete from OBJECT

[0236] where EID=33 and

[0237] delete from HIERARCHY

[0238] where EID=33

[0239] 3.1.8 Modify Entry

[0240] Navigate to the required entry. Store the EID. In the ObjectTable, Add, Remove or Modify rows matching the stored EID.

Example

[0241] Modify the entry “Datacraft/Sales/Network Products/Alana Morgan”.

[0242] Add value−title=“Branch Manager”.

[0243] Navigate to the entry and then;

[0244] select EID, AID, VID, VALUENORM from OBJECT

[0245] where EID=31

[0246] Test the returned rows for an attribute of title. If none exist,the attribute can be added, otherwise the attribute must be checked tosee if it can be multi-valued and whether it already exists.

[0247] Insert into OBJECT

[0248] (EID, AID, VID, DISTING, VALUENORM, VALUERAW)

[0249] values (31,12,1,0, BRANCH MANAGER, Branch Manager).

[0250] 3.1.9 Modify RDN

[0251] Navigate to the required entry. Check that the new name (RDN)does not exist in the current level of the subtree (i.e. that the new DNis distinct). Store the EID. Modify the entry in the Hierarchy andObject tables.

Example

[0252] Modify the RDN of the entry “Datacraft/Sales/NetworkProducts/Chris Masters” to “Christine Masters”.

[0253] Navigate to the entry and then;

[0254] select EID from HIERARCHY

[0255] where PARENT=20

[0256] and VALUENORM=“CHRISTINE MASTERS”

[0257] If no entries are returned then the new RDN may be inserted.First set the old RDN to be a non-distinguished value.

[0258] update OBJECT

[0259] set DISTING=0

[0260] where EID=30 and VALUENORM=“CHRIS” and

[0261] update HIERARCHY

[0262] set NAMENORM=“CHRISTINE MASTERS” and

[0263] set NAMERAW=“Christine Masters”

[0264] where EID=30 and

[0265] insert into OBJECT

[0266] (EID, AID, VID, DISTING, VALUENORM, VALUERAW)

[0267] values (30, 3, 1, 1, “CHRISTINE”, “Christine”)

[0268] 3.2 Search Strategy

[0269] The most powerful and useful X.500 service is the search service.The search service allows an arbitrary complex filter to be applied overa portion of the Directory Information Tree (the search area).

[0270] A filter is a combination of one or more filter items connectedby the operators AND, OR and NOT. For example; surname=“MASTERS” ANDtitle=“SALES MANAGER”

[0271] The Search area is the part of the tree that is covered by thescope of the search (base-object-only, one-level or whole-subtree).

[0272] One technique for resolving searches is to apply the filter andthen to see if any matching entries are in the search area. In this casea filter is applied to the entire tree and EID's for all rows matchingthe filter are returned. Then, for each EID found, step search upthrough the hierarchy to see if the entry is a subordinate of the baseobject (i.e. the entry has a parent/grandparent/ . . . that is the baseobject). If the number of matches is large and the subtree small this isvery inefficient. This technique doesn't cope with aliases as an aliasis not a parent of the object that it points to and many aliases maypoint to a single object.

[0273] A second strategy is to obtain a list of all EID's in the searcharea and then apply the filter to these EID's. If an alias is resolvedthat points outside of the original search area then the subtree pointedto by the alias is expanded and the EID's in that subtree are added tothe list. The filter is then applied to the set of expanded EID's. Thisis very poor if the search area is large.

[0274] An innovation is to simultaneously apply the filter over thesearch area (instead of sequentially as in the two methods describedabove). This is called single pass resolution. This method is consideredto provide considerable performance improvement over the above methodsbecause the rows that are retrieved are those that satisfy both thefilter and scope requirements of the search.

[0275] When performing a one level search the filter is applied to allentries that have a parent equal to the EID of the base object (forexample; search where parent=20 will apply the filter to entries 30, 31and 32).

[0276] When performing a subtree search the path is used to expand thesearch area. The “path” of each entry is a string of numbers (e.g.“1.10.50.222.” which indicates that entry 222 has a parent of 50, agrandparent of 10 and a great grandparent of 1). The path has the uniqueproperty that the path of an entry is a prefix of the path of allentries that are subordinate to the entry. That is the path of an entryforms the prefix of the paths of all entries in the subtree below theentry. Therefore when performing a subtree search we obtain the baseobject of the subtree and then apply the filter to all entries that havea path which is prefixed by the path of the base object (for example; tosearch for all entries under “Sales” we perform a search where PATH LIKE1.11%).

[0277] Base Object Search:

[0278] Navigate to the base object. Store the EID. In the Object Table,read nominated values from rows which match the stored EID where afilter criteria is satisfied, eg, telephone prefix=“727”.

Example

[0279] Search from the base object “Datacraft/Sales/Network Products”for an entry with surname=“MORGAN”, using a “base-object-only” search.Navigate to the base object and then;

[0280] select AID, VALUERAW from OBJECT

[0281] where EID=20 and AID=4

[0282] and NAMENORM=“MORGAN”

[0283] One Level Search:

[0284] Navigate to the base object. Store the EID. Return the list ofEID's which have a parent EID matching the stored EID (in Hierarchytable) and have values which satisfy the filter criteria (OBJECT table).In the Object Table, read nominated values for the returned EID's.

Example

[0285] Search from the base object “Datacraft/Sales/Network Products”for an entry with surname=“MORGAN”, using a “one-level-only” search.Navigate to the base object and then;

[0286] select H.EID from HIERARCHY H, OBJECT O

[0287] where PARENT=20 and AID=4 and NAMENORM=“MORGAN”

[0288] and H.EID=O.EID

[0289] then place the EID's returned into an EIDLIST and

[0290] select AID, VALUERAW from OBJECT

[0291] where EID in [EIDLIST]

[0292] Subtree Search:

[0293] Navigate to the base object. Store the EID. Return the list ofall EID's with a path like that of the base object (Hierarchy table) andhave values which satisfy the filter criteria (OBJECT table). In theObject Table, read nominated values for the returned EID's.

[0294] Example

[0295] Search from the base object “Datacraft/Sales/Network Products”for an entry with surname=“MORGAN”, using a “whole-subtree” search.Navigate to the base object and then;

[0296] select H.EID from HIERARCHY H, OBJECT O

[0297] where PATH like “1.11.20.%” and AID=4

[0298] and NAMENORM=“MORGAN”

[0299] and H.EID=O.EID

[0300] then place the EID's returned into an EIDLIST and

[0301] select AID, VALUERAW from OBJECT

[0302] where EID in [EIDLIST]

[0303] 3.3 Aliases and Navigate

[0304] Aliases are resolved during navigation if the“don't-dereference-alias” flag is not set and the service is not anupdate service (add, delete, modify, modifyRDN).

[0305] When an alias is discovered during navigation the alias must beresolved. That is, the object that the alias points to must be obtained.First we check the A_EID column of the Hierarchy table. If the A_EID is0 then the object that the alias points to must be obtained from theObject table and this object must then be navigated to and the resultantEID stored in the A_EID column. If this is done successfully then theremainder of the path can be navigated. By storing the EID of thealiased object in the A_EID column of the Hierarchy table it is possibleto avoid navigating to aliased objects. This can save time, especiallyif the aliased object is at a low level of the hierarchy.

[0306] 3.4 Aliases and Search

[0307] Aliases are dereferenced during a search if the “search-aliases”flag in the search argument is set. The performance of the searchservice while dereferencing aliases becomes a two step process. Firstly,define the search area and then apply the filter to the entries withinthe search area. Aliases dereferenced as part of the search service canexpand the search area to which the filter is applied. They alsorestrict the search area in that any dereferenced aliases are excludedfrom the search area.

[0308] Aliases and OneLevel Search

[0309] If aliases are being dereferenced as part of a one level searchand an alias entry is found then the alias must be resolved (using theObject table or the A_EID). The aliased object is then added to thesearch area to which the filter is applied. In a oneLevel search wherealiases are found the search area will consist of non-alias entriesdirectly subordinate to the base object and all dereferenced aliases.

[0310] Aliases and Subtree Search

[0311] If aliases are being dereferenced as part of a whole subtreesearch and an alias entry is found then the alias must be resolved(using the Object table or the A_EID) and this EID must then be treatedas another base object, unless it is part of an already processed subtree.

[0312] When dereferencing aliases during a search the “Path” column canbe used to find alias entries within a subtree join. If an alias entryis found that points outside of the current subtree then the subtreepointed to by the alias can also be searched for aliases. One propertyof the hierarchical tree structure is that each subtree is uniquelyrepresented by a unique base object (i.e. subtrees do not overlap). Whenperforming a subtree search we build up a list of base objects whichdefine unique subtrees. If no aliases are found then the list willcontain only one base object. If an alias is found that points outsideof the subtree being processed then we add the aliased object to thelist of base objects (unless one or more of the base objects aresubordinate to the aliased object in which case the subordinate baseobject(s) are replaced by the aliased object). The search area willtherefore consist of non-alias entries that have a path prefixed by thepath of one of the base objects.

[0313] 4. Logical Design

[0314] Whilst the Conceptual Design (see Table 4a) is sufficient toimplement the X.500 functionality, further performance improvements canbe made. TABLE 4a Conceptual Design Hierarchy Table EID Parent PathAlias A_EID NameNorm NameRaw Object Table EID AID VID Disting ValueNormValueRaw Attribute Table AID Type Syntax ObjectId

[0315] Performance improvements in conventional relational design can beachieved because assumptions can be made about the data—the data isessentially fixed at the time an application is designed. In X.500, noneof the data types are known. However performance improvements can stillbe made because assumptions can be made about the services—these areknown at the time the X.500 application is designed.

[0316] With reference to FIG. 2B, one innovative approach is torecognise that each table can be organised around the major servicerelationships (instead of around the major data relationships inconventional relational design). It shall be shown that the above tablescan be decomposed into a number of smaller and more efficient tables asshown below. TABLE 4b Logical Design DIT EID PARENT ALIAS RDN NAME EIDRAW TREE EID PATH ALIAS EID A_EID SEARCH EID AID VID DISTING NORM ENTRYEID AID VID RAW ATTR AID SYNTAX DESC OBJECTID

[0317] 4.1 Service Decomposition

[0318] The practical reality for most RDBMS's is that big tables withmany columns do not perform as well as smaller tables with fewercolumns. The major reasons are to do with indexing options, I/Operformance and table management (see Sections 4.5 and 4.6). This is whyprior art relational design techniques aim to focus primary informationinto separate tables and derive secondary information via table joins(i.e. normalisation and fragmentation techniques).

[0319] One innovation in achieving X.500 performance is to decompose thetables around primary service relationships and derive secondaryservices via joins. This process is called service decomposition. Thefollowing considerations are made:

[0320] (1) Columns that have strong relationships are preferred to bekept together (to avoid unnecessary joins);

[0321] (2) If the number of significant rows in a given column isindependent of the other related columns, then that given column is acandidate for a separate table.

[0322] (3) If a column is only used for locating information (input) oronly used for returning results (output) then it is a candidate for itsown table.

[0323] (4) If a column is used as a key for more than one service thenit is preferred to be a primary key and therefore in its own table (eachtable can have only one primary key).

[0324] (5) Keys are preferred to be unique or at least strong(non-repetitious).

[0325] A first level analysis of column usage is shown in Table 4.1.TABLE 4.1 Basic column usage X.500 Value Value Name Name Service TableEID AID VID Norm Raw Parent Alias Norm Raw Path Navigate H R S R S RRead O S (S)/R R R R R Compare O S S S List H S R R Search - O S/R S (S)(S) (S) filter Search - S/R (S)/R R R R R result Add H/O S Remove H/O SModify O S S S S Modify H/O S S S S RDN

[0326] Key to symbols in the above table:

[0327] H—Hierarchy table

[0328] O—Object table

[0329] S—Supplied value (used in the SQL for Searching the table)

[0330] R—Returned value (value retrieved from the tables)

[0331] ( )—item may or may not be present depending on the options ofthe service.

[0332] From the above information and further analysis, the ConceptualDesign tables can be decomposed into a number of smaller tables asdescribed in the following sections.

[0333] 4.2 Hierarchy Table Decomposition

[0334] The Hierarchy table contains the following columns: TABLE 4.2aHierarchy Table EID Parent Path Alias A_EID NameNorm NameRaw

[0335] The Hierarchy Table contains information about objects and theirparents, their names, their absolute positions in the hierarchy and ifthey are aliases. This table can therefore be split into four tables:DIT, NAME, TREE and ALIAS.

[0336] The parent information is used for finding a given child oracting on entries that have a given parent. Finding a given child (e.g.Parent=0, NameNorn=“DATACRAFT”) is the basis for Navigation and updatechecking (checking for the existence of an object before an Add orModifyRdn). Acting on entries that have a given parent is used duringList or OneLevel Search. Thus the DIT (Directory Information Tree) tablehas information required for Navigation, but allows its PARENT column tobe used by other services. TABLE 4.2b DIT Table EID PARENT ALIAS RDN

[0337] An object is differentiated from its siblings via its RelativeDistinguished Name (RDN). RDN's are returned for a List (in conjunctionwith a given Parent) or as part of a full Distinguished Name (Read,Search). Thus the NAME table has information required for returningnames (the raw RDN). TABLE 4.2c NAME Table EID RAW

[0338] An object's absolute position in the hierarchy is necessary forbuilding DN's (from which the raw RDN's are retrieved) and for expandingsubtrees during Search. Thus the TREE table has information about anentry's Path (the sequence of EID's down from the root). TABLE 4.2d TREETable EID PATH

[0339] Alias information is cached so that every time an alias isencountered during Navigate it does not have to be repeatedly resolved.Thus the ALIAS table only contains entries that are aliases. It is alsoused during OneLevel Search (in conjunction with the DIT Parent column)and Subtree Search (in conjunction with the Path column) to determine ifthere are any aliases in the search area. TABLE 4.2e ALIAS Table EIDA_EID

[0340] 4.3 Object Table Decomposition

[0341] The Object table contains the following columns: TABLE 4.3aObject Table EID AID VID Disting ValueNorm ValueRaw

[0342] The Object Table essentially contains information for finding aparticular value (e.g. AID=surname, ValueNorm=“HARVEY”) and forretrieving values (e.g. AID=surname, ValueRaw=“Harvey”). This table cantherefore be split into two tables: SEARCH and ENTRY.

[0343] The Search Table is used to resolve filters in the Searchservice. It is also used to find values during Compare, Modify andModifyRDN. The Search table contains one row for each attribute value ofeach entry. Only the normalised values are stored in this table. TABLE4.3b SEARCH Table EID AID VID DISTING NORM

[0344] The Entry table is used to return values in Reads and Searches.The Entry table contains one row for each attribute value for eachentry. The RAW value is the value exactly as initially supplied when theentry was added or modified. TABLE 4.3c ENTRY Table EID AID VID RAW

[0345] 4.4 Attribute Table

[0346] The Attribute table is essentially the same as the ConceptualDesign. In practice the “type” field is only descriptive, since anyincoming/outgoing X.500 Object Identifier gets converted to/from theinternal attribute identifier, AID. Thus this column has been renamedDESC to signify that it is a description field. TABLE 4.4 ATTR Table AIDSYX DESC ObjectId

[0347] 4.5 Index Selection

[0348] Performance when using SQL is achieved because the RDBMS is ableto satisfy the query using a relevant index. This means that every querythat has a condition (the “where” clause in SQL) is preferred to have anassociated index (otherwise the RDBMS has to resort to a table levelscan). However in practical RDMS's:

[0349] The number of indexes is restricted;

[0350] There may be a high overhead to maintain secondary indexes;

[0351] Composite indexes may be required to satisfy any one query. Thus,if performing a query across columns (e.g., type=surname andvalue=“SMITH”) then separate indexes on type and value may not result ina fully indexed access. A composite index on both type and value may berequired.

[0352] One innovation of the table decomposition in the previoussections is to maximise the use of primary indexes across tables. Thisreduces the number of secondary indexes (i.e. they become primaryindexes on their own table). Following is a list of the indexes for eachof the six tables used in the logical design. TABLE 4.5 Table indexesfor the Logical Design Table Primary Key Secondary Index DIT PARENT, RDNEID NAME EID TREE PATH EID SEARCH AID, NORM EID, AID, VID ENTRY EID,AID, VID ATTR (cached)

[0353] The table design means that many queries can be handled withoutjoins, giving substantial performance improvement.

[0354] The joins that are considered necessary are listed below:

[0355] List—for returning the RAW-RDNs under a given object (DIT joinedwith NAME).

[0356] Search/Subtree—for finding EIDs that match a filter over a wholesubtree (where the base object is not the root) (TREE joined withSEARCH).

[0357] Search/OneLevel—for finding EIDs that match a filter one-levelunder the base object (DIT joined with SEARCH).

[0358] Search/Aliases/Subtree—for finding all the aliases in a subtree(TREE joined with ALIAS).

[0359] Search/Aliases/OneLevel—for finding all the aliases under a givenobject (DIT joined with ALIAS).

[0360] Note that the above joins are first level joins (i.e. betweenonly two tables). It is preferable not to use higher order joins.

[0361] 4.6 Input/Output Performance

[0362] An innovation of decomposing tables around services, whichincreases the number of tables, is that the new tables are much smallerthan the unfragmented tables. This can significantly reduce the amountof I/O for the following reasons:

[0363] Row Size

[0364] By reducing the number of columns in any row, the row width willbe shortened. This means that more rows will fit onto a page (where itis assumed that one disk I/O returns one “page” of information). Incombination with clustering below, whenever a set of rows need to beretrieved, only one (or a few) page(s) may actually have to be read offthe disk (e.g. when reading the attributes of an object, if the ENTRYtable is keyed on EID, AID, VID then all the rows relating to thatobject will be together and will probably be on the same page).

[0365] Clustering

[0366] Each of the fragmented tables is preferred to have their own(independent) primary key which enables them to cluster data accordingto how it is used. The primary key may dictate the “storage structure”.Thus in the SEARCH table, if the primary key is on AID, NORM (i.e. type,value) then all the data of the same type (e.g. surname) and similarvalues (e.g. Harvey, Harrison) will be clustered in the same area of thedisk. This means that during a Search (e.g. surnames beginning with“HAR”) similar data will collected together on the one (or just a few)disk page(s). If the rows are small then the number of disk pages thathave to be accessed is significantly reduced.

[0367] Caching

[0368] Most commercial RDBMS's have the ability to cache pagesfrequently accessed. Since tables are effectively input (e.g. Navigatingusing the DIT table), or output (e.g. retrieving information from theENTRY table) then similar requests (e.g. Searches over the same portionof the Tree) will tend to result in frequently used pages being cached,meaning frequently invoked queries will gain significant benefits. Alsothe caching is more efficient since pages are “information intensive” asa result of small row size and clustering.

[0369] Management

[0370] Smaller tables are generally easier to manage: e.g. viewing,creating indexes, collecting statistics, auditing, backups, etc.

[0371] 5. Logical Methods

[0372] This section describes methods of interrogating the LogicalDesign tables, with reference to FIG. 2B.

[0373] Throughout this section, each X.500 method is defined andillustrated with an example. Referring again to FIG. 4, which will bereferred to in the following discussion as Table 5a, it can be seen thatTable 5a displays a small hierarchy tree which includes an aliasreference. The corresponding Table contents are shown in Table 5b. TABLE5b Example Tables DIT EID PARENT ALIAS RDN 1 0 0 DATACRAFT 10 1 1NETWORKS 11 1 0 SALES 12 1 0 MARKETING 20 11 0 NETWORK PRODUCTS 30 20 0CHRIS MASTERS 31 20 0 ALANA MORGAN 32 20 0 PETER EVANS NAME EID RAW 1[Datacraft] 10 [Networks] 11 [Sales] 12 [Marketing] 20 [NetworkProducts] 30 [Chris Masters] 31 [Alana Morgan] 32 [Peter Evans] TREE EIDPATH 1 1. 10 1.10. 11 1.11. 12 1.12. 20 1.11.20. 30 1.11.20.30. 311.11.20.31. 32 1.11.20.32. ALIAS EID A-EID 10 20 ATTRIBUTE AID SYX DESCOBJECTID 0 objectIdentifierSyntax objectClass 2.5.4.0 1distinguishedNameSyntax aliasedObjectName 2.5.4.1 3caseIgnoreStringSyntax commonName 2.5.4.3 4 caseIgnoreStringSyntaxsurname 2.5.4.4 7 caseIgnoreStringSyntax localityName 2.5.4.7 8caseIgnoreStringSyntax stateOrProvinceName 2.5.4.8 9caseIgnoreStringSyntax streetAddress 2.5.4.9 10 caseIgnoreStringSyntaxorganizationName 2.5.4.10 11 caseIgnoreStringSyntax organizational-2.5.4.11 UnitName 12 caseIgnoreStringSyntax title 2.5.4.12 13caseIgnoreStringSyntax description 2.5.4.13 16 PostalAddresspostalAddress 2.5.4.16 17 caseIgnoreStringSyntax postalCode 2.5.4.17 18caseIgnoreStringSyntax postOfficeBox 2.5.4.18 20 telephoneNumberSyntaxtelephoneNumber 2.5.4.20 SEARCH EID AID VID DISTING NORM 1 0 0 0 2.5.6.41 10 0 1 DATACRAFT 1 16 0 0 266-268 MAROONDAH HIGHWAY 1 17 0 0 3138 10 00 0 2.5.6.1 10 1 0 1 DATACRAFT/SALES/NETWORK PRODUCTS 11 0 0 0 2.5.6.511 11 0 1 SALES 11 13 0 0 SALES DEPARTMENT 12 0 0 0 2.5.6.5 12 11 0 1MARKETING 12 13 0 0 MARKETING DEPARTMENT 20 0 0 0 2.5.6.5 20 11 0 1NETWORK PRODUCTS 20 13 0 0 NETWORK PRODUCTS SECTION 30 0 0 0 2.5.6.7 303 0 1 CHRIS 30 4 0 1 MASTERS 30 12 0 0 SALES MANAGER 30 20 0 0 03 7279456 30 20 1 0 018 042 671 31 0 0 0 2.5.6.7 31 3 0 1 ALANA 31 4 0 1MORGAN 31 12 0 0 SALES SUPPORT 31 20 0 0 03 727 9455 32 0 0 0 2.5.6.7 323 0 1 PETER 32 4 0 1 EVANS 32 12 0 0 SALESPERSON 32 20 0 0 03 727 9454ENTRY EID AID VID RAW 1 0 0 [2.5.6.4] 1 10 0 [Datacraft] 1 16 0 [266-268Maroondah Highway] 1 17 0 [3138] 10 0 0 [2.5.6.1] 10 1 0[Datacraft/Sales/Network Products] 11 0 0 [2.5.6.5] 11 11 0 [Sales] 1113 0 [Sales Department] 12 0 0 [2.5.6.5] 12 11 0 [Marketing] 12 13 0[Marketing Department] 20 0 0 [2.5.6.5] 20 11 0 [Network Products] 20 130 [Network Products Section] 30 0 0 [2.5.6.7] 30 3 0 [Chris] 30 4 0[Masters] 30 12 0 [Sales Manager] 30 20 0 [(03) 727-9456] 30 20 1[(018)-042 671] 31 0 0 [2.5.6.7] 31 3 0 [Alana] 31 4 0 [Morgan] 31 12 0[Sales Support] 31 20 0 [(03) 727-9455] 32 0 0 [2.5.6.7] 32 3 0 [Peter]32 4 0 [Evans] 32 12 0 [Salesperson] 32 20 0 [(03) 727-9454]

[0374] 5.1 Common Services

[0375] Tree Navigation

[0376] All X.500 services rely on navigating the directory tree,illustrated in FIG. 3. The purpose of tree navigation is to retrieve theEID of the entry corresponding to the supplied Distinguished Name.Navigation begins from the root of the tree and continues down the treeuntil all the RDN's in a DN have been resolved (verified). This processis known as a “Tree Walk”.

[0377] The DIT Table is the primary table used for tree navigation.Referring to the example hierarchy tree, illustrated as table 5a in FIG.3, resolution of the DN “Datacraft/Sales/Network Products/Peter Evans”involves the following processes:

[0378] Scan the DIT table for a row containing PARENT=0 andRDN=“DATACRAFT”. The EID for this row is 1.

[0379] Scan the DIT table for a row containing PARENT=1 and RDN=“SALES”.The EID for this row is 11.

[0380] Scan the DIT table for a row containing PARENT=11 andRDN=“NETWORK PRODUCTS”. The EID for this row is 20.

[0381] Scan the DIT table for a row containing PARENT=20 and RDN=“PETEREVANS”. The EID for this row is 32.

[0382] The DN has now been resolved and any values relating to theobject can be obtained from the Entry Table using the key EID=32.

[0383] Aliases

[0384] Sometimes a DN can contain an alias, which is effectively anotherDN. Aliases complicate the tree walk process because the tree walkcannot continue until the alias is resolved. This requires a separatetree walk for the alias.

[0385] As an example, consider the DN “Datacraft/Networks/Peter Evans”.The first two steps in resolving this DN would be:

[0386] Scan the DIT table for a row containing PARENT=0 andRDN=“DATACRAFT”. The EID for this row is 1.

[0387] Scan the DIT table for a row containing PARENT=1 andRDN=“Networks” The EID for this row is 10.

[0388] At this stage we discover that this entry is an alias. The AliasTable is checked to see if the EID of the alias has been cached. If thisis the first time an attempt has been made to resolve this alias thenthe A_EID column in the Alias Table will be zero. For the purpose ofdiscussion it will be assumed that this is the first time.

[0389] To resolve the alias, the DN of the aliased object must bedetermined. This is stored in the “aliasedObjectName” attribute of thealias entry. The aliasedObjectName has an AID=1 (from the ATTR table)and so the DN is obtained from the Entry Table (RAW value) where EID=10and AID=1.

[0390] In this example, the DN of the alias is “Datacraft/Sales/NetworkProducts”. This DN is resolved completely using the normal tree walkingtechnique. The value of EID is 20.

[0391] At this stage, navigation continues for the unresolved RDN's inthe original DN, namely “PETER EVANS”. The last step required is then:

[0392] Scan the DIT table for a row containing PARENT=20 and RDN=“PETEREVANS”.

[0393] Once an alias has been resolved it can be added (cached) in theAlias Table. This table contains a reference, A_EID, to the aliasedobject. In the above example, an entry in the Alias Table with an EID of10 would have an A_EID of 20. Once an alias has been cached a tree walkis no longer necessary to resolve the alias.

[0394] Directory Paths

[0395] When objects are added to the DIT table, a corresponding row isadded to another table called the Tree Table. This table stores the listof the EID's which identify a “Path” to the object.

[0396] Distinguished Names

[0397] Most services require the distinguished name to be returned inthe Service Result. Using the directory path from the Tree Table, a DNcan be constructed from the RAW RDN values stored in the Name Table.

[0398] Entry Information Selection

[0399] Many of the X.500 Services are requested with an argument called“EntryInformationSelection” or EIS. The EIS argument is used to indicatewhat information in the Entry should be returned. Basically, EIS can beoptionally;

[0400] no information

[0401] attributes and values for selected or all attributes

[0402] values only for selected or all attributes

[0403] Entry Information

[0404] Entry Information is a return parameter for Read and Search. Italways contains the Distinguished Names of selected entries and,optionally, attributes and/or values as specified in the EIS argument ofthe request.

[0405] Common Arguments

[0406] All of the X.500 Services pass a set of common arguments in theService Request. Common Arguments contain information such as servicecontrols (time limit and size limit), the DN of the requestor of theservice and security information.

[0407] Common Results

[0408] Some X.500 Services pass a set of common results in the ServiceResponse. Common Results contain information such as securityparameters, the DN of the performer of the service and an aliasdereferenced flag.

[0409] 5.2 Read Service

[0410] A Read operation is used to extract information from anexplicitly identified entry. X.500 definition Description Argument NameA Distinguished Name EntryInformation- The attributes and values to bereturned (ie EIS) Selection Common Arguments Result Entry InformationThe DN plus any attributes and values returned Common Results

[0411] Method

[0412] Perform a tree walk using the DIT table, resolving aliases ifnecessary. Obtain the base EID.

[0413] Using PATH from the Tree Table and the RAW RDN's from the NameTable, build a DN.

[0414] If EIS specifies no attributes or values, just return the DN.

[0415] If EIS specifies ALL types and values, return the RAW values fromthe Entry Table for the matching EID.

[0416] If EIS specifies selected types and values, obtain the AID's fromthe Attribute Table and then return selected types and/or values for thematching EID.

Example

[0417] Read the entry “Datacraft/Sales/Network Products/Peter Evans”.

[0418] EIS is set to: attribute Types=allAttributes,InfoTypes=attributeTypesAndValues.

[0419] Using the DIT table perform a Tree Walk traversing EID's 1, 11,20 and 32 for the normalised RDN's DATACRAFT, SALES, NETWORK PRODUCTS,PETER EVANS. The EID of the selected object is 32.

[0420] Extract the PATH from the Tree Table for EID=32. The PATH is1.11.20.32.

[0421] Build aDN from the RAW values in the Name Table for EID's 1, 11,20, 32.

[0422] Using the Entry Table and the Attribute Table, for each matchingEID;

[0423] return the OBJECTID's from the Attribute Table and the ASN.1encoded RAW values from the Entry Table 2.5.4.0 [2.5.6.7] 2.5.4.3[PETER] 2.5.4.4 [EVANS] 2.5.4.9 [SALESPERSON] 2.5.4.20 [(03) 727-9454]

[0424] return the DN

[0425] 5.3 Compare Service

[0426] A Compare operation is used to compare a value (which is suppliedas an argument of the request) with the value(s) of/particular attributetype in a particular object entry. X.500 DEFINITION Description ArgumentName A Distinguished Name AttributeValue- The attribute type and valueto be compared Assertion Common Arguments Result DistinguishedName TheDN of the selected object (returned if an alias is dereferenced) matchedTRUE/FALSE result of compare fromEntry N/A Common Results

[0427] Method

[0428] Perform a tree walk using the DIT table, resolving aliases ifnecessary. Obtain the EID of the base object.

[0429] From the Attribute Table, obtain the AID of the attribute to becompared.

[0430] From the Entry Table, select the row(s) matching the EID and AID.

[0431] Compare the value.

[0432] Return TRUE or FALSE as the Compare result.

[0433] If an alias is dereferenced, return the DN of the selectedobject, using the path from the Tree Table and the RAW RDN's from theName Table.

Example

[0434] Compare the DN “Datacraft/Sales/Network Products/Peter Evans”with a purported AttributeValueAssertion of “title=[Salesperson]”.

[0435] Obtain the EID for the given DN using a TreeWalk. The EID of theselected object is 32.

[0436] Using the Attribute table, obtain the AID for “title”, ie AID=12.

[0437] Using the Search Table locate rows with EID=32 and AID=12 andtest for “NORM=SALESPERSON”.

[0438] Return TRUE or FALSE depending on the outcome of this test. Inthis instance the result would be TRUE.

[0439] Since no aliases were dereferenced, the DN of the entry is notreturned.

[0440] 5.4 List Service

[0441] A list operation is used to obtain a list of immediatesubordinates of an explicitly identified entry. X.500 DEFINITIONDescription Argument Name A Distinguished Name Common Arguments ResultDistinguishedName The DN of the selected object (returned if an alias isdereferenced) subordinates A list of RDN's for the subordinate entries(aliases, indicated by an alias flag, are not dereferenced)partialOutcomeQualifier An indication that an incomplete result wasreturned, eg, a time limit or size limit restriction. Common Results

[0442] Method

[0443] Perform a tree walk using the DIT table, resolving aliases ifnecessary. Obtain the EID of the base object.

[0444] Using the DIT and Name Tables return the ALIAS flag and the RAWRDN PARENT is equal to the EID of the base object.

Example

[0445] Perform a list for the DN “Datacraft”.

[0446] Obtain the EID for the DN using a TreeWalk. The EID of theselected object is “1”.

[0447] For each EID with a PARENT=1

[0448] return the RAW RDN from the Name Table, ie, [Networks], [Sales],[Marketing]

[0449] return the alias flags, ie, TRUE, FALSE, FALSE.

[0450] As no alias was dereferenced in the tree walk, the DN of theselected object is not returned. Note also that the alias entry[Networks] is not dereferenced.

[0451] 5.5 Search Service

[0452] The Search Service is the most complex of all X.500 services.Search arguments indicate where to start the search (baseObject), thescope of the search (subset), the conditions to apply (filter) and whatinformation should be returned (selection). In addition, a flag ispassed to indicate whether aliases should be dereferenced(searchAliases).

[0453] The possible values for subset are baseObject, oneLevel andwholeSubtree. Base object indicates that the search filter will only beapplied to attributes and values within the base object. OneLevelindicates the Search filter will be applied to the immediatesubordinates of the base object. Whole subtree indicates the Searchfilter will be applied to the base object and all of its subordinates.

[0454] A simple example of a filter condition would be: surname=“EVANS”or telephoneNumber PRESENT. X.500 DEFINITION Description ArgumentbaseObject The Distinguished Name of the baseObject subset baseObject,oneLevel or wholeSubtree filter search conditions searchAliases a flagto indicate whether aliases among subordinates of the base object shouldbe dereferenced during the search. selection EIS as for READ. Theattributes and values to be returned. Common Arguments ResultDistinguishedName The DN of the selected object (returned if an alias isdereferenced) entries Attributes & values (as defined in selection) forthe entries which satisfy the filter. partialOutcomeQualifier Anindication that an incomplete result was returned, eg, a time limit orsize limit restriction. Common Results

[0455] The search procedures for each search scope are outlined asfollows:

[0456] Base Object

[0457] Perform a tree walk using the DIT table, resolving aliases ifnecessary. Obtain the EID of the base object.

[0458] Apply the filter to attributes and values in the Search Tablewith the EID of the selected object.

[0459] If the filter condition is matched, return the Entry Informationfrom the Entry Table.

[0460] If an alias is dereferenced, return the DN using the Tree Tableto extract the PATH and the Name Table to build the DN.

[0461] One Level

[0462] Perform a tree walk using the DIT table, resolving aliases ifnecessary. Obtain the EID of the base object.

[0463] Check to see if any aliases exist with PARENT=EID and if soresolve them to obtain an aliases dereferenced list.

[0464] Using the Search and DIT Tables, apply the filter(attribute/value conditions) and the scope (PARENT=EID of selectedobject and any aliases dereferenced). A list of matching EID's will bereturned.

[0465] If an alias is dereferenced, return the DN using the Tree Tableto extract the PATH and the Name Table to build the DN.

[0466] For each matching EID:

[0467] Return the Entry Information obtained from the Search Table usingthe Entry Table (as per Read Service).

[0468] Whole Subtree

[0469] Perform a tree walk using the DIT table, resolving aliases ifnecessary. Obtain the EID of the base object.

[0470] Check to see if any aliases exist with PATH prefix matching thePATH of the selected object.

[0471] For each alias discovered, check to see if the alias pointsoutside the current subtree and if it does repeat the previous step.Once all aliases have been resolved, a set of unique base objects willhave been found (with no overlapping areas).

[0472] Using the Search and Tree Tables, apply the filter(attribute/value conditions) and the scope (PATH LIKE PATH prefix of theselected object) to each unique base object. A list of matching EID'swill be returned.

[0473] If an alias is dereferenced during Navigation (not duringsearching), return the DN using the Tree Table to extract the PATH andthe Name Table to build the DN.

[0474] For each matching EID:

[0475] Return the Entry Information obtained from the Search Table usingthe Entry Table (as per Read Service).

Example

[0476] Perform a search on the baseObject “Datacraft/Sales” with:

[0477] Scope set to WholeSubtree

[0478] a Filter of “surname, substring initial=M”. (Look for allsurnames beginning with “M”)

[0479] SearchAliases set to TRUE.

[0480] EIS set to attribute Types=allAttributes,InfoTypes=attributeTypesAndValues.

[0481] Method

[0482] Obtain the EID for the base object DN using a TreeWalk. The EIDof the base object is “11”.

[0483] From the Tree Table, obtain the PATH for EID=11, ie, “1.11”.

[0484] Check for any aliases among entries that have a path beginningwith “1.11.”. There are no aliases in this case.

[0485] Obtain the AID for the attribute “surname” in the AttributeTable, ie, 4.

[0486] Apply the filter and scope simultaneously. i.e. Using the SearchTable, obtain a list of EID's from the target list where AID=4 and thevalue begins with “M” joined with the Tree Table who's PATH is LIKE‘1.11.%’. The matching EID's are 30 and 31.

[0487] Using the Entry Table and the Attribute Table, for each matchingEID:

[0488] return the OBJECTID's from the Attribute Table and the ASN.1encoded RAW values from the Entry Table i.e., 2.5.4.0, [2.5.6.7],2.5.4.3, [Chris], 2.5.4.4 [Masters] 2.5.4.9 [Sales Manager] 2.5.4.20[(03) 727-9456] 2.5.4.20 [(018)-042 671] 2.5.4.0 [2.5.6.7] 2.5.4.3[Alana] 2.5.4.4 [Morgan] 2.5.4.9 [Sales Support] 2.5.4.20 [(03)727-9454]

[0489] 5.6 Add Entry Service

[0490] An AddEntry operation is used to add a leaf entry either anobject entry or an alias entry) to the Directory Information Tree. X.500DEFINITION Description Argument object The Distinguished Name of theentry to be added entry A set of attributes to add Common ArgumentsResult NULL NULL

[0491] Method

[0492] Using the DIT table, tree walk to the parent of the entry to beadded (Parent EID).

[0493] Using the DIT table, check if the entry exists (check for RDN=newRDN and PARENT=Parent EID).

[0494] If the entry does not exist, allocate a new EID and add theentry. Insert into the DIT Table, the Name Table, the Tree Table, theSearch Table, the Entry Table and, if it is an alias entry, the AliasTable.

Example

[0495] Under the object with a DN of “Datacraft/Marketing” add an objectwith the following attributes and values. surname [Delahunty] commonName[Mary] title [Marketing Manager] telephoneNumber [(03) 727-9523]

[0496] Obtain the EID for the base object DN using a TreeWalk. The EIDof the base object is “12”.

[0497] Using the DIT Table, look for a duplicate entry, ie, PARENT=12and RDN=“MARY DELAHUNTY”. No duplicates exist.

[0498] Add the following rows to the Tables shown. DIT EID PARENT ALIASRDN 33 11 0 MARY DELAHUNTY NAME EID RAW 33 [Mary Delahunty] TREE EIDPATH 33 1.12.21. SEARCH EID AID VID DISTING NORM 33 0 0 0 2.5.6.7 33 3 01 DELAHUNTY 33 4 0 1 MARY 33 12 0 0 MARKETING MANAGER 33 20 0 0 03 7279523 ENTRY EID AID VID RAW 33 0 0 [2.5.6.7] 33 3 0 [Delahunty] 33 4 0[Mary] 33 12 0 [Marketing Manager] 33 20 0 [(03) 727-9523]

[0499] 5.7 Remove Entry Service

[0500] A RemoveEntry operation is used to remove a leaf entry (either anobject entry or an alias entry) from the Directory Information Tree.X.500 DEFINITION Description Argument object The Distinguished Name ofthe entry to be deleted Common Arguments Result NULL NULL

[0501] Method

[0502] Perform a tree walk using the DIT table. Obtain the EID of thebase object.

[0503] If the entry exists, and it is a leaf entry, then for thecondition EID=EID of the selected object, delete from the DIT Table, theName Table, the Tree Table, the Search Table, the Entry Table and, if itis an alias entry, the Alias Table.

Example

[0504] Delete the object with a DN of “Datacraft/Marketing/MaryDelahunty”

[0505] Method

[0506] Obtain the EID for the base object DN using a TreeWalk. The EIDof the base object is “21”. Check that no entries have PARENT=21.

[0507] Delete all rows added to the DIT Table, the Name Table, the TreeTable, the Search Table and the Entry Table (refer to Add Entry example)where EID=21.

[0508] 5.8 Modify Entry Service

[0509] The ModifyEntry operation is used to perform a series of one ormore of the following modifications to a single entry:

[0510] add a new attribute

[0511] remove an attribute

[0512] add attribute values

[0513] remove attribute values

[0514] replace attribute values

[0515] modify an alias X.500 DEFINITION Description Argument object TheDistinguished Name of the entry to be modified changes A list ofmodifications Common Arguments Result NULL NULL

[0516] Method

[0517] Perform a tree walk using the DIT table. Obtain the EID of theselected object.

[0518] For the selected object, perform one or more of the followingactions: Add Value, Delete Value, Add Attribute, Delete Attribute

[0519] The operations required for each action are as follows:

[0520] Add Value

[0521] If the attribute exists, add the value to the Entry Table and theSearch Table. Checks are: If the attribute is single valued test for anexisting value; if the attribute is multi-valued check for a duplicatevalue.

[0522] Delete Value

[0523] For the Entry Table and the Search Table, if the value exists,delete it. A Distinguished Value cannot be deleted.

[0524] Add Attribute

[0525] If the attribute does not exist, add the Attribute Values to theEntry Table and the Search Table.

[0526] Delete Attribute

[0527] For the Entry Table and the Search Table, if the attributeexists, delete it. Delete all values with AID=attr and EID=base object.Naming attributes cannot be deleted.

Example

[0528] Modify the Entry “Datacraft/Sales/Network Products/Chris Masters”with the following changes:

[0529] Delete Attribute and Value telephoneNumber 018-042 671

[0530] Modify Attribute and Value title Sales Assistant

[0531] The Search and Entry Tables reflect the changes. SEARCH EID AIDVID DISTING NORM 30 0 0 0 2.5.6.7 30 3 0 1 CHRIS 30 4 0 1 MASTERS 30 120 0 SALES ASSISTANT 30 20 0 0 03 727 9456 ENTRY EID AID VID RAW 30 0 0[2.5.6.7] 30 3 0 [Chris] 30 4 0 [Masters] 30 12 0 [Sales Assistant] 3020 0 [(03) 727-9456]

[0532] 5.9 Modify RDN Service

[0533] The ModifyRDN operation is used to change the RelativeDistinguished Name of a leaf entry (either an object entry or an aliasentry) from the Directory Information Tree. Description Arguments objectThe Distinguished Name of the entry to be modified newRDN The new RDN ofthe entry deleteOldRDN flag - delete all values in the old RDN not innew RDN Common Arguments Result NULL NULL

[0534] Method

[0535] Perform a tree walk using the DIT table. Obtain the EID andParent EID of the base object.

[0536] Using the DIT table, check for equivalent entries and returnerror if one is found. An equivalent entry has RDN=new RDN andPARENT=Parent EID.

[0537] Using the Name Table, replace the old RDN with the new RDN.

[0538] Using the DIT Table, replace the old RDN with the new RDN.

[0539] Using the Entry Table, insert the new value.

[0540] Using the Search Table, locate value=old RDN and set DISTING to0. Insert the new value.

[0541] If deleteOldRDN is set to TRUE the procedures following the TreeWalk are as follows:

[0542] Using the DIT table, check for a sibling with the same name andan EID not equal to the base EID

[0543] Using the Name Table, replace the old RDN with the new RDN.

[0544] Using the DIT Table, replace the old RDN with the new RDN.

[0545] Using the Entry Table, delete the old value(s) and insert the newvalue(s).

[0546] Using the Search Table, delete the old value(s) and insert thenew value(s).

Example

[0547] Modify the RDN of “Datacraft/Sales/Network Products/ChrisMasters”. The new RDN is “Christine Masters”.

[0548] deleteOldRDN is set to FALSE.

[0549] The changes to the Tables will be as follows: DIT EID PARENTALIAS RDN 21 11 0 CHRISTINE MASTERS NAME EID RAW 21 [Christine Masters]SEARCH EID AID VID DISTING NORM 30 0 0 0 2.5.6.7 30 3 0 1 CHRISTINE 30 31 0 CHRIS 30 4 0 1 MASTERS 30 12 0 0 SALES ASSISTANT 30 20 0 0 03 7279456 ENTRY EID AID VID RAW 30 0 0 [2.5.6.7] 30 3 0 [Christine] 30 3 1[Chris] 30 4 0 [Masters] 30 12 0 [Sales Assistant] 30 20 0 [(03)727-9456]

[0550] 5.10 Complications

[0551] If error, limit or abandon occurs during processing of any of theservices, then the processing is discontinued and an appropriate errormessage returned.

[0552] Errors

[0553] Each X.500 service consists of 3 parts; ARGUMENT, RESULT andERRORS. In the above descriptions of the services, ARGUMENT and RESULThave been included in the X.500 definitions. Error conditions, however,are many and varied and no attempt is made to describe them in thisdocument. The National Institute of Standards and Technology (NIST)document “Stable Implementation Agreements for Open SystemsInterconnection Protocols: Version 3” provides a full coverage of errorsfor the X.500 standard.

[0554] Time Limit & Size Limit

[0555] Time Limit and Size Limit form part of Service Controls. They canbe optionally set to some finite limit and included in the CommonArguments.

[0556] Time Limit indicates the maximum elapsed time, in seconds, withinwhich the service shall be provided. Size Limit (only applicable to Listand Search) indicates the maximum number of objects to be returned. Ifeither limit is reached an error is reported. For a limit reached on aList or a Search, the result is an arbitrary selection of theaccumulated results.

[0557] Abandon

[0558] Operations that interrogate the Directory, ie Read, Compare, Listand Search, may be abandoned using the Abandon operation if the user isno longer interested in the results.

[0559] Aliases & Search

[0560] If an alias is encountered in a search and that alias points to aseparate branch of the directory tree, then dereferencing of the aliasrequires:

[0561] Navigation from the root entry to the referenced entry

[0562] Searching of all items subordinate to the referenced entry

[0563] In the example shown in FIG. 5, if a WholeSubtree Search wasperformed on a base object of “Telco/Corporate/Data Services” theentries “Mervyn Purvis” and the alias “Strategic” would be searched.Strategic, however, points to a different branch of the tree whichrequires searching of the entry “Strategic” and all of its subordinates,ie, “Alan Bond”, “Rex Hunt”, “Wayne Carey” and “John Longmire”.

[0564] 5.11 Implementation Optimisations

[0565] The Logical methods include a number of optimisations thatenhance performance. These methods are outlined below.

[0566] Caching

[0567] The Attribute table can be cached. This means that (apart frominitial loading of the attributes) no SQL statements need to be issuedto the database when decoding or encoding the attributes. In the presentX.500 system attribute conversions are performed in memory. Thisprovides a substantial speed advantage.

[0568] Validation

[0569] Query validation is performed in memory where possible. Thisavoids database rollbacks which are time and system consuming. Forexample when adding an entry each attribute is validated before anyattempt is made to add the entry. If an error is found then no SQL callsneed to be issued.

[0570] Optimise Query Handling

[0571] As the format of most services is known, many instances of theseservices can be resolved using static SQL statements. More complexservices, such as searches with complex filters, can be resolved usingdynamic SQL. This enables arbitrarily complex searches to be performed.

[0572] Parallel Queries

[0573] Also when processing search results the present system utilisesset orientation queries of SQL to avoid ‘row at a time’ processing. Thussearch results may be assembled in parallel in memory.

[0574] Data Storage

[0575] The tables that store raw data store the data in ASN.1 format.This provides an efficient means of transferring data into or out of thedatabase.

[0576] Database Techniques

[0577] Complex services can be further improved by using the queryoptimiser, which provides a mechanism for reducing the time spent inresolving the query. The use of a relational database also provides anefficient use of memory and enables large databases to be constructedwithout the need for large amounts of memory being available. Many otherX.500 applications cache the entire database in memory to achieveperformance. This method consumes large amounts of memory and is notscalable.

[0578] 6. Physical Design

[0579] The physical design results from a process called physicaltransformation of the logical design. The physical design represents apreferred realisation or embodiment of the logical design. FIG. 2B andthe tables below show one form of the physical design. New columns andtables are highlighted by double borders. TABLE 6 Physical Design DIT

NAME

TREE

INFO

ALIAS

SEARCH

ENTRY

BLOB

ATTR

SENTRY

OCLASS

[0580] 6.1 Efficiency

[0581] INFO Table

[0582] This table holds the highest EID value that has been used in thedatabase. The inclusion of the INFO table enables the next EID to beobtained without any calculation of the maximum EID being performed bythe database. This provides improved efficiency in adding entries to thedatabase. More importantly the inclusion of the INFO table removescontention problems which may occur when multiple DSA's are addingentries at the same time.

[0583] Shadow Keys

[0584] Three tables have had shadow keys added. These are:

[0585] a) The NORMKEY column in the SEARCH table.

[0586] b) The RDNKEY column in the DIT table.

[0587] c) The LEV1, LEV2, LEV3 and LEV4 columns in the TREE table.

[0588] Each of these shadow key columns is a shortened version of alarger column. They have been added to shorten the indexes on eachtable. This gives improved performance for any queries that use theindexes and it also improves disk space usage as small indexes take upless space than large indexes.

[0589] The shadow keys in the PATH table utilise the structured natureof the PATH. By being a composite key then exact matching can be used inthe SQL instead of the “LIKE” operator.

[0590] e.g. WHERE LEV1=1 AND LEV2=10 AND . . .

[0591] instead of WHERE PATH LIKE ‘1.10.%’.

[0592] If each of the LEV columns has their own index, then a sub-treesearch needs to only use the base object. e.g. LEV2=10, since allobjects under entry 10 will have LEV2=10.

[0593] SENTRY Table

[0594] Some types of attribute values do not need to be normalised e.g.integer, boolean, date. Instead of storing them twice (SEARCH.NORM andENTRY.RAW) they can be stored just once in a hybrid table called theSENTRY table. This reduces table sizes and increases storage efficiencyat the cost of having to search two tables and retrieve from two tables.

[0595] OCLASS Table

[0596] Most attributes have a wide variation in their values e.g.surnames could range from AALDERS to ZYLA with a great many differentvalues in between. However, Object Classes (whose values areObjectIdentifiers or OIDs) have very few values e.g. in an organisationof 10,000 people, the only object classes in the directory may be fororganisation, organisationalUnit and organisationalPerson (of which manymay be the latter). The OCLASS table gives a numeric descriptor to anobject class called an OCID. The OCID can then be stored in the SENTRYtable and a mapping done whenever an Object Class is searched orretrieved. The other LIST columns store standard object classsuperclasses.

[0597] 6.2 Portability

[0598] BLOB Table

[0599] This table has been included to hold “Binary Large Objects”. Themaximum size of a one row entry in the ENTRY table is limited by thelength of the RAW field. This means that entries must be fragmented.Fragmented entries will occupy more than one row and so a VFRAG fieldmust be used to denote the fragment of the entry that is being stored ina particular row.

[0600] There are two options for storing very large values:

[0601] a) Add a “fragment flag” to the ENTRY table and store the entryin fragments over a number of lines; or

[0602] b) Add a BLOB table to store the entry and add a “BLOB flag” tothe ENTRY table to indicate that this value is stored in the BLOB.

[0603] The second option has a number of advantages. Firstly, theinclusion of a BLOB table prevents the ENTRY table from becomingexcessively large. Generally most entries will be less than a fewhundred characters in length, so the length of the RAW field in theENTRY table can accordingly be reduced to cater for those entries andthe RAW field in the BLOB table can be increased to a value approachingthe maximum record size. This will make storage more efficient, i.e.reduce the amount of unused bytes in each column of each table andreduce the number of fragments needed for each entry in the BLOB table.It also means that each value will have only one entry in the ENTRYtable and that the ENTRY and SEARCH tables maintain their one-to-onecorrelation. Secondly the use of a BLOB table enables the application tomake use of any database support for Binary Large Objects (e.g. 64KBinary Columns).

[0604] 6.3 Functional Extensibility

[0605] FLAGS Columns

[0606] FLAGS column(s) are preferred to be added. These column(s) havebeen added to provide extensibility to the design. Specific values canbe added to the flags as new functionality is required, without changingthe table structure.

[0607] Note:

[0608] a) In the SEARCH table, the DISTING field may be absorbed intothe FLAGS field.

[0609] b) In the DIT table, the ALIAS field may be absorbed into theFLAGS field.

[0610] The FLAGS column(s) may also provide a “summary” function foreach of the tables. This means that the nature of an entry can bedetermined to some extent by checking the value of the FLAGS field. Forexample, a flag can be set, in the DIT table, when an entry is a leaf.Checking this flag is much simpler than checking for children of theentry.

[0611] The FLAGS column can also be used to store security information,whether an alias points inside its parents sub-tree, whether a value isa BLOB, etc.

[0612] 7. Example Implementation

[0613] The following provides an example of system performance andcapabilities. It is to be understood that the present inventions shouldnot be limited to the following disclosure.

[0614] 7.1 Overall System Benefits

[0615] The present invention is considered to provide enhancedperformance over prior art implementations. Performance can be appraisedin many ways, including:

[0616] aliases;

[0617] size (use of relational theory);

[0618] complexity (use of query optimiser and search method(s));

[0619] extensibility (use of meta-data); and

[0620] substantially without degrading efficiency (use of disk basedmodel) and reliability (use of RDBMS).

[0621] The present invention is considered unique in its ability toclaim performance improvement in all areas noted above.

[0622] 7.2 Test Results

[0623] Performance testing of the present invention has been carriedout, with the objectives of:

[0624] Proving that an SQL based X.500 application can perform atsubsecond speeds, dispelling a widely held myth in the marketplace thatit is impossible to implement an X.500 DSA application as an integratedRDBMS application and achieve efficiency and performance.

[0625] Proving that the design of an SQL based X.500 application canoutperform existing memory resident style X.500 designs, especially fordatabases in excess of 100K entries, a typical limit of current designs.

[0626] Providing a structured suite of tests that can demonstrate theabove performance on demand for a wide variety of services and databasesizes. Service Database Size (number of entries) Operation QualifierDetail 1K 10K 20K 50K 100K 200K BIND anonymous 0.00 0.00 0.00 0.00 0.000.00 LIST level 1 4 items 0.05 0.05 0.05 0.05 0.05 0.05 level 3 4 items0.06 0.06 0.06 0.06 0.06 0.06 level 4 100 items 0.22 0.23 0.23 0.24 0.230.24 READ level 4 1 item, all info 0.07 0.07 0.07 0.07 0.07 0.08 level 4(via alias) 1 item, all info 0.07 0.07 0.07 0.07 0.07 0.07 SEARCH 1level, equality 100 entries, 1 item 0.12 0.12 0.12 0.12 0.13 0.13 1level, initial 100 entries, 1 item 0.13 0.14 0.15 0.15 0.15 0.14 1level, any 100 entries, 1 item 0.30 0.35 0.33 0.32 0.36 0.29 1 level,final 100 entries, 1 item 0.24 0.35 0.31 0.30 0.35 0.28 subtree,equality 1K, 1 item, level 1 0.11 0.11 0.11 0.11 0.11 0.11 10K, 1 item,level 1 xxx xxx 0.12 0.12 0.12 0.12 20K, 1 item, level 1 xxx xxx xxx0.12 0.13 0.12 50K, 1 item, level 1 xxx xxx xxx xxx 0.13 0.13 100K, 1item, level 1 xxx xxx xxx xxx xxx 0.12 subtree, initial 1K, 1 item,level 1 0.13 0.12 0.12 0.12 0.12 0.11 10K, 1 item, level 1 xxx xxx 0.110.12 0.12 0.12 20K, 1 item, level 1 xxx xxx xxx 0.13 0.12 0.12 50K, 1item, level 1 xxx xxx xxx xxx 0.13 0.12 100K, 1 item, level 1 xxx xxxxxx xxx xxx 0.11 full, complex OR all entries, 1 item 0.09 0.09 0.090.09 0.09 0.09 full, complex AND all 0.11 0.11 0.11 0.11 0.11 0.11entries, 1 item full, complex OR/AND all 0.26 0.28 0.29 0.28 0.29 0.26entries, 1 item full, complex AND/OR all 0.12 0.12 0.13 0.14 0.13 0.12entries, 1 item full, complex AND/AND all 0.16 0.15 0.16 0.17 0.18 0.18entries, 1 item full, complex all entries, 1 item 0.18 0.18 0.18 0.190.20 0.26 AND/AND/AND full, equality all entries, 1 item 0.08 0.08 0.080.08 0.08 0.08 full, no filter, all-info all 0.30 0.74 0.43 0.59 0.490.67 entries, 10 items full, no filter, all-info all 1.36 1.84 1.50 1.791.82 1.86 entries, 100 items full, initial all entries, 1 item 0.08 0.080.08 0.08 0.08 0.08 ADD level 5 100 sisters 0.22 0.19 0.22 0.20 0.190.19 MODIFY level 5 100 sisters 0.09 0.11 0.11 0.11 0.11 0.11 RENAMElevel 5 100 sisters 0.15 0.16 0.15 0.16 0.16 0.15 DELETE level 5 100sisters 0.17 0.16 0.17 0.17 0.17 0.19 UNBIND 0.00 0.00 0.00 0.00 0.000.00

[0627] 7.3 Test Conclusions

[0628] A set of directories was constructed ranging from 1K to 200Kentries with varying depth and width of the hierarchy, and acorresponding test plan was produced. The tests were performed a numberof times to ensure consistency.

[0629] The following conclusions can be drawn from these results;

[0630] 1. The effects of navigation, in test, were negligible.

[0631] 2. Reading an object via an alias, in test, showed no appreciabledecrease in performance and in some cases reading an object via an aliaswas in fact faster than reading the object directly. This is due to thereduced navigation required when an alias points “down” to an objectthat is deeper in the tree structure than the alias entry.

[0632] 3. Search results were “flat” over different sized subtrees indifferent sized directories for both exact and initial string searches.

[0633] 4. Initial and exact full tree searches, in test, were slightlyquicker than their respective subtree searches, even though the numberof entries searched was greater. This is due to the fact that the fulltree searches are able to use more efficient SQL (no table joins arerequired).

[0634] 5. All services were, in test, performed in under one second,except for searches returning large amounts of data. However the averagetime of retrieval per-entry drops as the number of entries retrievedincreases (e.g for 10 entries retrieval time is approximately 50milliseconds per entry, for 100 entries this drops to approximately 20milliseconds per entry).

[0635] 6. All complex searches, in test, were performed in under onesecond. However, there may be some obscure searches (e.g containingcombinations of NOT) which may not perform as well.

[0636] Because this is a disk based system (rather than a memory basedsystem) performance is essentially only dependent on the number ofentries actually returned. It is relatively independent of the searchcomplexity, the depth of the hierarchy, the number of attributes perentry or the types of attributes used in the query. In a “live”application of the system it may be possible to improve on the achievedtest results by tuning the caching parameters, and by having a greaterdiversity of attributes.

We claim:
 1. A directory service arrangement comprising a data baseusing a plurality of tables, each table having a plurality of rows andcolumns, said tables being organised corresponding to their function. 2.A directory service arrangement as claimed in claim I wherein saidplurality of tables comprises at least a first table allowing a newattribute type to be defined by adding a row to the table, a secondtable defining the attributes within each object, and a third tabledefining the relationship between objects.
 3. A directory servicearrangement comprising: a database using a plurality of tables, eachtable having a plurality of rows and columns, and storing arbitrarydata, and means for processing said arbitrary data using a fixed set ofqueries/services.
 4. A directory service arrangement as claimed in claim3, wherein said database is a relational database.
 5. A directoryservice arrangement as claimed in claim 4, wherein said databasesupports the structured query language (SQL).
 6. A method of providingtables in a directory service apparatus, comprising: establishing aplurality of tables in a directory service apparatus, each of saidtables comprising a plurality of columns, and defining the plurality oftables on the basis of corresponding functions related to said services.7. A method as claimed in claim 6, wherein each service is modeled andthe relationships among said services is predetermined.
 8. A method asclaimed in claim 6, in which services provided by the directory serviceare performed at least partially in a database that supports SQL.
 9. Amethod as claimed in claim 7, in which services provided by thedirectory service are performed at least partially in a database thatsupports SQL.
 10. A method of processing arbitrary data in a directoryservice apparatus, said apparatus comprising a plurality of tablesestablished on the basis of respective functions, the method includingthe step of: processing the arbitrary data using a fixed set ofqueries/services.
 11. A method of managing data in a directory servicearrangement supporting at least one of X.500 or LDAP services, whereindata is identifiable by a predetermined criteria and is stored in adatabase medium, the method comprising the step of: clustering data ofthe same criteria in the same area of the database medium.
 12. A methodas claimed in claim 11, wherein the criteria comprises data type.
 13. Amethod as claimed in claim 11, wherein the criteria comprises entryidentifier (EID).
 14. A method as claimed in claim 11, wherein thecriteria comprises a parent identifier.
 15. A method as claimed in claim11, wherein the criteria compirises data type and value.
 16. A method asclaimed in claim 11, wherein the criteria comprises parent identifierand entry name.
 17. A method as claimed in claim 11, wherein thecriteria comprises attribute type for the purpose of a search.
 18. Amethod as claimed in claim 11, wherein the criteria comprises attributetype and similar value(s) for the purpose of a search.
 19. A method asclaimed in claim 11, further comprising: searching clustered data on thebasis of the criteria.
 20. A method as claimed in claim 12, furthercomprising: searching clustered data on the basis of the criteria.
 21. Amethod as claimed in claim 13, further comprising: searching clustereddata on the basis of the criteria.
 22. A method as claimed in claim 14,further comprising: searching clustered data on the basis of thecriteria.
 23. A method as claimed in claim 15, further comprising:searching clustered data on the basis of the criteria.
 24. A method asclaimed in claim 16, further comprising: searching clustered data on thebasis of the criteria.
 25. A method as claimed in claim 17, furthercomprising: searching clustered data on the basis of the criteria.
 26. Amethod as claimed in claim 18, further comprising: searching clustereddata on the basis of the criteria.
 27. The invention as hereindisclosed.
 28. A method of managing data as claimed in claim 11, whereinthe step of clustering data comprises: clustering data of similarcriteria for the purpose of retrieving data.
 29. A method of managingdata as claimed in claim 12, wherein the step of clustering datacomprises: clustering data of similar criteria for the purpose ofretrieving data.
 30. A method of managing data as claimed in claim 13,wherein the step of clustering data comprises: clustering data ofsimilar criteria for the purpose of retrieving data.
 31. A method ofmanaging data as claimed in claim 14, wherein the step of clusteringdata comprises: clustering data of similar criteria for the purpose ofretrieving data.
 32. A method of managing data as claimed in claim 15,wherein the step of clustering data comprises: clustering data ofsimilar criteria for the purpose of retrieving data.
 33. A method ofmanaging data as claimed in claim 16, wherein the step of clusteringdata comprises: clustering data of similar criteria for the purpose ofretrieving data.
 34. A method of managing data as claimed in claim 17,wherein the step of clustering data comprises: clustering data ofsimilar criteria for the purpose of retrieving data.
 35. A method ofmanaging data as claimed in claim 18, wherein the step of clusteringdata comprises: clustering data of similar criteria for the purpose ofretrieving data.
 36. A method of managing data as claimed in claim 28,further comprising: retrieving clustered data on the basis of thecriteria.
 37. A method of managing data as claimed in claim 29, furthercomprising: retrieving clustered data on the basis of the criteria. 38.A method of managing data as claimed in claim 30, further comprising:retrieving clustered data on the basis of the criteria.
 39. A method ofmanaging data as claimed in claim 31, further comprising: retrievingclustered data on the basis of the criteria.
 40. A method of managingdata as claimed in claim 32, further comprising: retrieving clustereddata on the basis of the criteria.
 41. A method of managing data asclaimed in claim 33, further comprising: retrieving clustered data onthe basis of the criteria.
 42. A method of managing data as claimed inclaim 34, further comprising: retrieving clustered data on the basis ofthe criteria.
 43. A method of managing data as claimed in claim 35,further comprising: retrieving clustered data on the basis of thecriteria.
 44. A method of managing data as claimed in claim 17, whereinthe step of clustering data comprises: clustering said data around nodesfor the purpose of navigating.
 45. A method of managing data as claimedin claim 44, further comprising navigating in said database on the basisof said clustered data.
 46. A method of managing data as claimed inclaim 11, wherein the step of data clustering is effected by adding atleast one index to each of a plurality of tables.
 47. A method ofmanaging data as claimed in claim 12, wherein the step of dataclustering is effected by adding at least one index to each of aplurality of tables.
 48. A method of managing data as claimed in claim13, wherein the step of data clustering is effected by adding at leastone index to each of a plurality of tables.
 49. A method of managingdata as claimed in claim 14, wherein the step of data clustering iseffected by adding at least one index to each of a plurality of tables.50. A method of managing data as claimed in claim 15, wherein the stepof data clustering is effected by adding at least one index to each of aplurality of tables.
 51. A method of managing data as claimed in claim16, wherein the step of data clustering is effected by adding at leastone index to each of a plurality of tables.
 52. A method of managingdata as claimed in claim 17, wherein the step of data clustering iseffected by adding at least one index to each of a plurality of tables.53. A method of managing data as claimed in claim 18, wherein the stepof data clustering is effected by adding at least one index to each of aplurality of tables.
 54. A method of managing data as claimed in claim28, wherein the step of data clustering is effected by adding at leastone index to each of a plurality of tables.
 55. A method of managingdata as claimed in claim 29, wherein the step of data clustering iseffected by adding at least one index to each of a plurality of tables.56. A method of managing data as claimed in claim 30, wherein the stepof data clustering is effected by adding at least one index to each of aplurality of tables.
 57. A method of managing data as claimed in claim31, wherein the step of data clustering is effected by adding at leastone index to each of a plurality of tables.
 58. A method of managingdata as claimed in claim 32, wherein the step of data clustering iseffected by adding at least one index to each of a plurality of tables.59. A method of managing data as claimed in claim 33, wherein the stepof data clustering is effected by adding at least one index to each of aplurality of tables.
 60. A method of managing data as claimed in claim34, wherein the step of data clustering is effected by adding at leastone index to each of a plurality of tables.
 61. A method of managingdata as claimed in claim 35, wherein the step of data clustering iseffected by adding at least one index to each of a plurality of tables.62. A method of arranging tables of a directory service arrangement, forproviding directory services, comprising primary services and secondaryservices, the method comprising the steps of: a. decomposing tablesaround primary service relationships, and b. deriving secondary servicesvia joins.
 63. A method as claimed in claim 62, in which in saiddecomposing step, at least one of the following consideration are made:(i) columns that have strong relationships are to be kept together,thereby avoiding unnecessary joins; (ii) if the number of significantrows in a given column is independent of the other related columns, thenthat given column is considered a candidate for a separate table; (iii)if a column is only used for locating information as an input, or onlyused for returning results as an output, then it is considered acandidate for its own table; (iv) if a column is used as a key for morethan one service, then it is considered a primary key and therefore acandidate for its own table; or (v) keys are to be unique or at leaststrong and not repetitious.
 64. A method of decomposing a principaldatabase design, having a PROPERTY table comprising at least a columnfor object name and parent name, in a directory service system, themethod including the step of: applying functional decomposition to thePROPERTY table, and deriving a conceptual design having a HIERARCHYtable, an OBJECT table, and an ATTRIBUTE table.
 65. A method ofdecomposing a conceptual design in a directory service system offering aplurality of services and being operative with a database having aplurality of tables, including a HIERARCHY table and an OBJECT table,each comprising a plurality of columns, the method including the stepsof: a. applying service decomposition to said HIERARCHY table, therebyderiving at least two table(s) comprising a DIT (Directory InformationTree) table having information required for navigation, a NAME tablehaving information required for returning names, including raw relativedistinguished name (RDN), a TREE table having information about anentry's path, and an ALIAS table having entries that are aliases: and b.applying service decomposition to said OBJECT table, thereby deriving atleast two tables, a SEARCH table for resolving filters in a Searchservice, said SEARCH table including one row for each attribute value ofeach entry, and an ENTRY table for returning values in Read and Searchservices, said ENTRY table having one row for each attribute value ofeach entry, and c. deriving a logical design having tables defined insteps a and b above and an ATTR (ATTRIBUTE) table.
 66. A method ofdecomposing a logical design of a directory service system into aphysical design, comprising the steps of: applying physicaldecomposition to the logical design, thereby deriving the physicaldesign.
 67. A directory service system for one or more objects, whereinsaid system comprises: a plurality of tables according to a principaldesign, a conceptual design and a logical design, wherein said principaldesign comprises at least one table which is a PROPERTY table.
 68. Adirectory service system as claimed in claim 67, further comprising aplurality of tables according to a conceptual design.
 69. A directoryservice system as claimed in claim 67, further comprising a plurality oftables according to a logical design.
 70. A directory service system asclaimed in claim 68, further comprising a plurality of tables accordingto a logical design.
 71. A directory service system as claimed in claim67, wherein the PROPERTY table has columns comprising at least onecolumn for each of the following items: an object name, comprising thename of said object; a parent name, comprising the name of a parent ofsaid object; a type, comprising the type of a value of said object; asyntax, comprising the form of a value of said object; and value,comprising the contents of a value of said object.
 72. A directoryservice system as claimed in claim 68, wherein the PROPERTY table hascolumns comprising at least one column for each of the following items:an object name, comprising the name of said object; a parent name,comprising the name of a parent of said object; a type, comprising thetype of a value of said object; a syntax, comprising the form of a valueof said object; and value, comprising the contents of a value of saidobject.
 73. A directory service system as claimed in claim 69, whereinthe PROPERTY table has columns comprising at least one column for eachof the following items: an object name, comprising the name of saidobject; a parent name, comprising the name of a parent of said object; atype, comprising the type of a value of said object; a syntax,comprising the form of a value of said object; and value, comprising thecontents of a value of said object.
 74. A directory service system,having a plurality of tables arranged in a conceptual design, whereineach table comprises a plurality of columns, said system comprising: aHIERARCHY table, adapted to contain information about objects,comprising their parents, their names, their relative positions in ahierarchy, and if they are aliases, for defining the structuralrelationship between objects; an OBJECT table, adapted to containinformation for finding a particular value and for retrieving values,for defining the attribute values within each object; and an ATTRIBUTEtable, adapted to contain information about the attributes of object(s).75. A system as claimed in claim 74, wherein the HIERARCHY tablecomprises a separate column for at least an entry ID (EID) whichcorrelates each object with its hierarchy information, a Parent value,and a Name value, the OBJECT table comprises a separate column for atleast an EID value, an attribute ID (AID) value which correlates eachvalue in the OBJECT table with its attribute information, a valueidentifier (VID) to identify values within an attribute in the OBJECTtable, a Disting value to flag attribute values for naming an entry, andat least one value for each object attribute, and the ATTRIBUTE tablecomprises a separate column for at least an AID value, a Type valuewhich identifies object type, a Syntax value which identifies objectform, and an object identifier (ObjectID) for conversion betweendirectory service identifiers and internal attribute identifiers.
 76. Adirectory service system, comprising a plurality of tables, each havinga plurality of columns, and being arranged in a logical design, saidtables comprising one or more of: a directory information tree (DIT)table, having information for navigation; a TREE table, havinginformation about the sequence of EID's down from the root; an ALIAStable, having information about entries that are aliases; a NAME table,having information required for returning names; a SEARCH table, havinginformation used to resolve filters in a search service and find valuesduring other services; an ENTRY table, which is used to return values inReads and Searches, with one row being used for each attribute value ofeach entry; and an ATTRIBUTE table, which describes information aboutattributes of entry(s).
 77. A directory services system as claimed inclaim 76, wherein the DIT table has EID, Parent, Alias and RDN columns,the TREE table has EID and Path columns, the ALIAS table has EID andA_EID columns, the NME table has EID and Raw columns, the SEARCH tablehas EID, AID, VID, Disting, and Norm columns, the ENTRY table has EID,AID, VID and Raw columns, and the ATTRIBUTE table has AID, Syx, Desc andObjectid columns.
 78. A directory services system comprising a pluralityof tables, each having a plurality of columns, and being arranged in aphysical design, said tables comprising one or more of the following: adirectory information tree (DIT) table, having information fornavigation; a TREE table, having information about the sequence of EID'sdown from the root; an ALIAS table, having information about entriesthat are aliases; a NAME table, having information required forreturning names; a SEARCH table, having information used to resolvefilters in a search service and find values during other services; anENTRY table, which is used to return values in Reads and Searches, withone row being used for each attribute values of each entry; an INFOtable, which holds the highest EID value that has been used in thedatabase; a SENTRY table, which stores attribute values in raw formalone, where they do not need to be normalized; a BLOB table, whichstores binary large objects that are greater in size than that of theENTRY table; an ATTRIBUTE table, which stores information aboutattributes of entry(s); and an OCLASS table, which provides informationabout object class(es) in entry(s).
 79. A system as claimed in claim 38,wherein the DIT table has EID, Parent, Rdnkey, Rdn and Flags columns,the TREE table has EID, Lev1, Lev2, Lev3, Lev4, Path and Flags columns,the ALIAS table has EID, A_EID, and Flags columns, the NAME table hasEid, Raw and Flags columns, the INFO table has Maxeid and Flags columns,the SEARCH table has EID, AID, VID, Normkey, Norm and Flags columns, theENTRY table has EID, AID, VID, Raw and Flags columns, the SENTRY tablehas EID, AID, VID, Value and Flags columns, the BLOB table has EID, AID,VID, Vfrag, Raw and Flags columns, the ATTRIBUTE table has AID, Syx,Desc, Objectid and Flags columns, and the OCASS table has Ocid, Desc,Objectid, Mustlist, Maylist, Superlist and Flags columns.
 80. Animplementation of directory services in a RDBMS which supports arelational language, using service modeling, the implementationcomprising: an ATTRIBUTE table, where extensibility is provided byallowing the definition of a new attribute type by adding a row to thetable; an OBJECT table, which defines the attributes within each object;and a HIERARCHY table which defines the relationship between theobjects.
 81. The implementation of claim 80 wherein said OBJECT tablecomprises normalized value columns and raw value columns.
 82. Theimplementation of claim 80 wherein said HIERARCHY table comprises anormalized name column and a raw name column.
 83. The implementation ofclaim 80 wherein the HIERARCHY table further comprises an alias columnfor indicating that an entry is an alias.
 84. The implementation ofclaim 83 wherein the alias column comprises an alias and an A-EID columnproviding information about the destination to which the alias points.85. The implementation of claim 83, wherein the HIERARCHY tablecomprises a parent column with parent ID information defining the parententry, and a path column, the path column containing informationenabling a determination of the absolute position in a hierarchy and adetermination if an entry is in a given subtree by its prefix.
 86. Amethod of implementing a data service in a RDBMS data base whichsupports a relational language, having a fixed set of queries/servicesdefined by service modeling, the method comprising: defining anATTRIBUTE table, where extensibility is addressed by allowing thedefinition of a new attribute type by adding a row to the table;defining an OBJECT table, which defines the attributes within eachobject; and/or defining a HIERARCHY table which defines the relationshipbetween the objects; and providing arbitrary data entries to saidATTRIBUTE table; and processing said arbitrary data using said fixed setof queries/services.
 87. The method of claim 86 further comprising thestep of using the ATTRIBUTE table for incoming data to find theattribute ID (AID) from the directory service object ID for an outgoingdata read from the database.
 88. The method of claim 86 furthercomprising the step of utilising a path field to simultaneously apply anarbitrary filter over an arbitrary subtree.
 89. The method of claim 87further comprising storing in said at least one of said tables the pathof each entry as a string of entry ID values.
 90. The method of claim 86further comprising: caching the values from the ATTRIBUTE table; andperforming conversions and validations in memory.
 91. The method ofclaim 86 further comprising: decomposing the tables around primaryservice relationships and deriving secondary services via joins.
 92. Themethod of claim 91 further comprising: keeping together columns thathave strong relationships to avoid unnecessary joins; making a column aseparate table if: the number of significant rows in said column isindependent of the other related columns; and said column is only usedfor locating information (input) or only used for returning results(output); and said column is used as a key for more than one service.93. The method of claim 91 further comprising splitting a HIERARCHYtable into a plurality of tables comprising columns for at least the id,name, tree and alias.
 94. The method of claim 91 further comprisingsplitting the OBJECT table into a plurality of tables comprising atleast a SEARCH table used to resolve filters in search service and findvalues during compare, rename and modify operations.
 95. The method ofclaim 91 further comprising resolving an alias by determining the end ofthe alias object and cashing the alias in an ALIAS table containing areference to the alias.
 96. The method of claim 95 further comprisingaccessing, adding, or deleting a row to a tree table, and storing a listof IDs which identify a path to an object, when objects are added to theDIT table.
 97. A data arrangement for implementing directory services ina RDBMS which supports a relational language, having a fixed set ofqueries/services defined by service modeling, the data arrangementcomprising: an extensible ATTRIBUTE table, comprising information aboutattributes; an OBJECT table, comprising data which defines theattributes within each object; and/or a HIERARCHY table, comprising datawhich defines the relationship between the objects.
 98. The dataarrangement as set forth in claim 97 wherein said data in said ATTRIBUTEtable is arranged as at least one column for each of type, syntax anddescription.
 99. The data arrangement as set forth in claim 97 whereinsaid HIERARCHY table is arranged as at least a column for parent andchild.
 100. The data arrangement of claim 97, wherein said HIERARCHYtable is arranged with data values comprising an entry identifier (EID)in a column, said EID for correlating each object with its hierarchyinformation.
 101. The data arrangement of claim 97, wherein the OBJECTtable is arranged with data values comprising an entry identifier (EID)in a column and an attribute identifier (AID) which correlates eachvalue in the OBJECT table with its attribute information.
 102. The dataarrangement of claim 97, wherein the ATTRIBUTE table further comprisesan object id column so that conversions between object identifiers andthe internal attribute identifiers can be performed.
 103. The dataarrangement of claim 102, wherein said OBJECT table further comprises avalue identifier (VID) to identify values within an attribute in theOBJECT table.
 104. The data arrangement of claim 97 wherein the OBJECTtable further comprises a column to flag distinguished values (DISTING)for naming an entry.
 105. The data arrangement of claim 104 whereindistinguished values combine to form a relative distinguish name (RDN)which names an entry.
 106. The data arrangement of claim 97 where bothnormalized data and raw data are stored in the database and theHIERARCHY and OBJECT tables include columns for normalized and rawinputs, respectively.
 107. A directory service system implementing themethod of any one of claims 11-46.
 108. The method as recited in any oneof claims 62-66, wherein said directory service arrangement comprisesone of a LDAP and X.500 directory service.
 109. The directory servicesystem as recited in any one of claims 67-79 wherein said system is oneof a X.500 and a LDAP service system.
 110. The implementation of adirectory service system as claimed in any one of claims 80-85 whereinsaid system is one of X.500 and a LDAP service system.
 111. The methodas recited in any one of claims 86-96 wherein said directory servicecomprises one of a LDAP and X.500 directory service.
 112. The dataarrangement of any one of claims 97-106, in which the directory servicesare X.500 or LDAP services.
 113. A computer program product comprising acomputer program storage medium containing therein a computer programoperable in accordance with the method recited in any one of claims 6-66and 86-96.